[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] dyngen porting - workaround for st_size==0
From: |
Herbert Poetzl |
Subject: |
Re: [Qemu-devel] dyngen porting - workaround for st_size==0 |
Date: |
Thu, 8 Jul 2004 01:36:07 +0200 |
User-agent: |
Mutt/1.4.1i |
On Wed, Jul 07, 2004 at 04:06:41PM +0300, address@hidden 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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel