Hello,

I am using a special-patched gcc 4.0.2 toolchain to compile the DSLINUX 
repository. It's an ARM946es Linux 2.6.14 system.

My goal is to compile c++ programs. I have plugged uClibc++ into the 
uClinux system (because I want the lowest-cost-c++-runtime), and 
my "far goal" is to compile PIXIL to give the DS a graphical 
environment.

But as soon as I have a vtable, my programs crash. The compiler is 
called with -fpic -msingle-pic-base.

Here is what I found so far:

with 

> arm-linux-elf-objdump -C -D -z rtest.o

I get in function main():

>  f0:   e5943000        ldr     r3, [r4]
>  f4:   e1a00004        mov     r0, r4
>  f8:   e1a0e00f        mov     lr, pc
>  fc:   e593f000        ldr     pc, [r3]

R4 has the pointer to the object.
R3 is loaded with the pointer to the VTABLE
PC is loaded with the address in the first slot of the VTABLE.

So, the GCC assumes that in the VTABLE, there are the absolute addresses 
of the functions.

If I dump the VTABLE at runtime, there are no absolute addresses in it, 
only offsets like 0x0F8, 0x0108, etc....

> rm-linux-elf-objdump -C -D -z rtest.o 

gives me:

> Disassembly of section .gnu.linkonce.d._ZTV5test1:
>
> 00000000 <vtable for test1>:
>    0:   00000000        andeq   r0, r0, r0
>    4:   00000000        andeq   r0, r0, r0
>    8:   00000000        andeq   r0, r0, r0
>    c:   00000000        andeq   r0, r0, r0
>   10:   00000000        andeq   r0, r0, r0
>   14:   00000000        andeq   r0, r0, r0

and

> arm-linux-elf-objdump -r rtest.o  

gives me:

> RELOCATION RECORDS FOR [.gnu.linkonce.d._ZTV5test1]:
> OFFSET   TYPE              VALUE
> 00000008 R_ARM_ABS32       _ZN5test14selfEv
> 0000000c R_ARM_ABS32       _ZN5test15selfaEv
> 00000010 R_ARM_ABS32       _ZN5test15selfbEv
> 00000014 R_ARM_ABS32       _ZN5test15selfcEv

Obviously, theses relocations must be done AT LOAD TIME, because only 
the binfmt loader in the kernel knows the program start address.

I have given the -v option to elf2flt, and I DO NOT SEE these 
relocations. And in the linked program in BFLT v4 format, they are not 
in the relocation table.

So I think I have to blame efl2flt for that. The "version" is 
elf2flt-20051225.

Does this sound familiar to someone? What should I do to debug this 
problem?

regards

Wolfgang
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to