Re: [Qemu-devel] TCG flow vs dyngen

[Raphaël Lefèvre]

2011/1/17 Stefano Bonifazi <address@hidden>:
>
> Hi!
> Thank you very much for Your concern!
> Honestly I had lost hope in any help, I even contacted directly some
> developers in this mailing list without luck!

I guess many good developers in mailing list are still try their best
to solve your problems, such as Blue Swirl, Paolo Bonzini, Stefan
Weil, Peter Maydell, Mulyadi Santosa, Andreas Färber and Alexander
Graf (hope I won't lost anyone that had helped you, and the order of
name list without any meaning) ...etc., every developer has his
expertises, and it is hard to recognize all of the activities of qemu.
Please trust one thing: you are not alone:).

> I am a student who needs to use qemu for a project where it will be used for
> its capabilities of running PowerPC code.
> As you can imagine qemu goes far beyond the knowledge in electronics and
> computer science of a student. Nevertheless I have to do that!
> I have been studying all the possible technical documents available in the
> internet, but it is really not much at all , not sufficient for getting the
> code and being able of understanding it .. It is in C, even not modular C++

Due to the lack of tehnical document of qemu and you are a student
(maybe study for master/phd degree?), some literatures that published
on IEEE/ACM may give you some inspiration and help (suppose that your
university have bought the authority for download). As I know, though
the issue of qemu is relative new for the academia, there still are
literatures have been discussed. Maybe you can find which research
domain categorized that is most approximative to your works. If any
literature has inspired you or related to your research, don't
hasitate to discuss.

> Anyway with some help from this mailing list, and a lot of studying about
> assembly, loaders, compilers.. I am going on, though there are still big
> problems due of the nature of the QEMU code..
> First of all, I am starting from qemu-user, more specifically, qemu-ppc as I
> don't need the full system capabilities, and it is easier for me to control
> the binary target memory with qemu-user.

Is there any reason why should you use the user mode of qemu, not the
system mode? Sometime, the system mode of qemu will release you from
the nightmare for managing the memory hierarchy. Maybe you can start
from talking about what is the original goal of the project instead of
falling into the hell of code tracing.

> Originally I started with a lot of work on libqemu .. until some developer
> here told me it was deprecated (though still in the source) and not working
> fine.
> I edited the code of qemu-ppc so that another function of mine calls
> qemu-user main, with the appropriate parameters.. The pursued goal was to
> launch it several times with different target binaries in succession..
> For some reason, I still can't find out, qemu code remembers the old code,
> running it instead of the new loaded binary.. and if I flush the cache of
> translated code before loading a new binary it stops and can't go on!
> My workaround to this problem was compiling qemu-ppc as a dynamic library
> and load it at runtime.. I also managed to load multiple copies of it (with
> dlmopen each at a different address space) ..in fact I need to run more than
> one qemu-ppc at the same time but a new big problem popped up now: the

I need to thanks the Peter Maydell explained the principle that I'm
not familiar with. And from your description, would you want to invoke
multi-cores? Because I cannot imagine which application need to run
multiple qemu-ppc at the same time.

> target binary is loaded always at a fixed address.. no matter if another
> qemu-ppc already loaded code there.. it is like the internal elf loader
> can't understand those addresses are not available, and then relocate them
> ..
> I tried to link (ld) the binary target elf as position independent code, but
> then qemu-ppc complains it can't find  /usr/lib/libc.so.1 and
>  /usr/lib/ld.so.1
>

The above description seems to be out of my scope to answer, because I
only studied on system mode of qemu.

> To sum up the problems are (in order of importance):
>  - making the elf loader relocate the target code into other addresses when
> the default ones (I guess those embedded into the target binary when it is
> not compiled as position independent code) are taken

Maybe the problem only can be solved by re-write the loader if you
insist to use user mode. (just as your response to Peter)

>  - making qemu-user able of running more than one target binary in
> succession

Will m"ore than one target binary in succession (assume A then B then
C)" be achieved by "compile ABC into one binary in sequence"?

>  - counting qemu-user executed instructions

I guess all the works before this are for the goal: "counting
qemu-user executed instructions", am I right? If so, the paper
published in IEEE 2010 maybe give some help (I guess)
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=5475901 (Make
sure that your university can access it)

Raphaël Lefèvre