State of C++ support in Toolchain/DSLINUX
amadeus at iksw-muees.de
Thu Jul 19 15:38:40 CEST 2007
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
> 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
> 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
> arm-linux-elf-objdump -r rtest.o
> 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?
We're back to the times when men were men
and wrote their own device drivers.
More information about the dslinux-devel