State of C++ support in Toolchain/DSLINUX

Amadeus amadeus at iksw-muees.de
Thu Jul 19 15:38:40 CEST 2007


Hello,

in the last days, I have integrated uClibc++ into DSLINUX.

uClibc++ is the smallest available C++ support library.

I have tried to test uClibc++, but stucked in user/rtest.

RTEST is a small C++ test program. Currently, it allocates a C++ object 
with a virtual function. Calling the virtual function results in a 
crash.

My investigations:

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. And 
this loader fails, perhaps because the vtable is in the DATA segment 
and not in the code segment (the code segment is assumed to be R/O) 
because of possible XIP (?!?)

Any ideas how to debug this problem?

Amadeus
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)



More information about the dslinux-devel mailing list