Re: [Qemu-devel] TCG flow vs dyngen

[Stefano Bonifazi]

> Sorry for my belated on this discussion, after I searched for the
> topics you posted, it seems two main problems are unsolved? (Am I
> right?? I'm not sure...)
>
> 1. "I edited QEMU user, more exactly qemu-ppc launching the main function
> (inside main.c) from another c function I created, passing it the
> appropriate parameters. ...balabala" at Jan, 2011
>
> 2. "how can I check the number of target cpu cycles or target
> instructions executed inside qemu-user (i.e. qemu-ppc)?
> Is there any variable I can inspect for such informations?" at Dec, 2010
>
> If I'm not correct, please let me know where the problem is.
>
> Raphaël Lefèvre
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 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++
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.
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 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

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
 - making qemu-user able of running more than one target binary in 
succession
 - counting qemu-user executed instructions

My university is a public one, so my project will be open to the 
community, I will also upload the documentation I am writing about qemu 
coming from the knowledge I am acquiring working on it, so that, I hope, 
other people will find less frustrating the first steps into developing 
qemu!

Any help will be more than welcome!

Thank you in advance!
Stefano B.