[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] dyngen porting - workaround for st_size==0
From: |
alonl |
Subject: |
[Qemu-devel] dyngen porting - workaround for st_size==0 |
Date: |
Wed, 7 Jul 2004 16:06:41 +0300 (IDT) |
User-agent: |
SquirrelMail/1.5.0 |
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
- [Qemu-devel] dyngen porting - workaround for st_size==0,
alonl <=