Re: [Qemu-devel] TCG flow vs dyngen

[Stefano Bonifazi <stefboombastic@gmail.com>]

Hi!
  In case you are interested in helping me, I'll give you a big piece of 
news I've just got (even my teacher is not informed yet! :) )
I've just managed to make more than one instance of qemu-user run at the 
same time linking the target code with a specified address for the code 
section (-Ttext address of ld).
It works fine and this proves my idea that the problem is within the elf 
loader..
Making it relocate the target code properly would fix the problem ;)
Now let's work on it :)
Regards,
Stefano B.

On 01/16/2011 08:02 PM, Stefano Bonifazi wrote:
> Thank you very much for Your fast reply!
>
>
> On 01/16/2011 07:29 PM, Peter Maydell wrote:
>> Linux doesn't seem to have dlmopen
> http://www.unix.com/man-page/All/3c/dlmopen/
>
> #define __USE_GNU
> #include <dlfcn.h>
>
> lib_handle1 = dlmopen(LM_ID_NEWLM,"./libqemu-ppc.so", RTLD_NOW);
>
> I am developing that on a clean ubuntu 10.10
>> but google suggests that it puts the library in its own namespace
>> but not its own address space.
> I need to make the different instances of qemu-user exchange data .. 
> obviously keeping all of them in the same address space would be the 
> easiest way (unless I have to change all qemu code ;) ) Running each 
> qemu as its own
>> process and using interprocess communication for whatever
>> coordination you need between the various instances seems
>> more likely to be workable to me. This will also fix your "can't run
>> more than one binary in succession" problem, because you can
>> just have the first qemu run and exit as normal and launch a
>> second qemu to run the second binary.
>>
>> -- PMM
> Exactly, it was the easiest way also for me.. and I've already done 
> it, works smoothly .. the only big problem is that it is not good for 
> my teacher.. he says it should work the dynamic library way o.O
> Working with libraries even solved the problem of consecutive runs, 
> though according to me it is not good a software when you must reboot 
> it for making it run again fine.. sounds more Windows style :D
> Clearly it makes memory "dirty" and do not clean after the target 
> process completes its execution.. leaving the OS care about it.
> I tried zeroing all global variables before starting a new execution 
> without results (other than making it stall) .. After very long time 
> spent trying to find a solution I think the problem should be with the 
> mmap' ings stuff in the loader .. the same reason why 2 different 
> libraries with their own namespaces clash according to me.. the elf 
> loaders work globally within the unique address space .. I think for a 
> guru of loaders-linkers should not be so difficult to patch it.. but 
> not for a student who almost heard about them for the first time  ;)
> Any help is very appreciated :)
> Thank you again!
> Stefano B.
>
>
>