[Qemu-devel] dyngen porting - workaround for st_size==0

[Qemu-devel] dyngen porting - workaround for st_size==0

[alonl]

Hi,

 I'm compiling qemu using the nisa-elf compiler, a cross compiler for the
BF533, a dsp by analog devices. After some tweaking I managed to compile
dyngen and a bunch of other files, until the point where dyngen is
executed to create op.h and opc.h.

 At that point I get error messages that complain about empty code for
_op_SOMETHING (sorry for no pasted make logs - I'm writing this on a
different machine. btw the added underscore is a change I had to make
since the nisa-elf compiler produces function symbols with that
underscore prepended). I looked into dyngen and found that it was ok, the
problem is that the elf objects that nisa-elf-gcc produces have
sym->st_size == 0! This doesn't prevent them from running at the end, but
it prevents me from compiling qemu.. let alone running it..

 I can't change the st_size field without hacking the toolchain, which is
very hard - is there any way to make dyngen work without the size field?
will any of the following work:
 sort the symbols according to st_value (address), and take the difference
to be the size that the JIT should copy.
 or: from st_value look for the RTS opcode (10 00 for the BF533, a 16 bit
instruction processor), assuming there is only one for each function.

 Any other ideas are appreciated, help!

Alon

Re: [Qemu-devel] dyngen porting - workaround for st_size==0

[Herbert Poetzl]

On Wed, Jul 07, 2004 at 04:06:41PM +0300, alonl@tiranogath.dnsalias.net wrote:
> Hi,
> 
>  I'm compiling qemu using the nisa-elf compiler, a cross compiler for the
> BF533, a dsp by analog devices. After some tweaking I managed to compile
> dyngen and a bunch of other files, until the point where dyngen is
> executed to create op.h and opc.h.
> 
>  At that point I get error messages that complain about empty code for
> _op_SOMETHING (sorry for no pasted make logs - I'm writing this on a
> different machine. btw the added underscore is a change I had to make
> since the nisa-elf compiler produces function symbols with that
> underscore prepended). I looked into dyngen and found that it was ok, the
> problem is that the elf objects that nisa-elf-gcc produces have
> sym->st_size == 0! This doesn't prevent them from running at the end, but
> it prevents me from compiling qemu.. let alone running it..
> 
>  I can't change the st_size field without hacking the toolchain, which is
> very hard - is there any way to make dyngen work without the size field?
> will any of the following work:
>  sort the symbols according to st_value (address), and take the difference
> to be the size that the JIT should copy.
>  or: from st_value look for the RTS opcode (10 00 for the BF533, a 16 bit
> instruction processor), assuming there is only one for each function.

how about that: define a label at the end of the
code, something like _op_SOMETHING_end, and just
use/store the difference between this and the _op
symbol ...

>  Any other ideas are appreciated, help!

HTH,
Herbert

> Alon
> 
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel