This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
R_386_32 relocations with sym-value=0 ?
- From: Nils Asmussen <nils at script-solution dot de>
- To: binutils at sourceware dot org
- Date: Mon, 16 Aug 2010 16:54:56 +0200
- Subject: R_386_32 relocations with sym-value=0 ?
Hi!
First, some background: I'm developing my own hobby-OS for x86 and using
a gcc-cross-compiler (4.4.3) and binutils (2.20) as toolchain. I provide
my own (small) libc and libstdc++, but use libgcc.a, libsupc++.a,
crtbegin.o and crtend.o from gcc. I have also implemented (not complete,
though) my own dynamic linker.
Now, I'm running into a problem when linking libstd++ and libc
dynamically to a c++-application that wants to throw/catch exceptions.
As far as I've figured it out yet, the problem is that the typeinfo of
the exception isn't relocated correctly.
To come back to the subject: Currently I'm building the libstdc++.so
with:
i586-elf-escape-ld -shared -soname libstdc++ -o libstdc++.so <object
files> -lc
I don't know if thats the problem. When I try to build it with g++, as
one would normally do:
i586-elf-escape-g++ -shared -nostartfiles -nostdlib -Wl,-soname,libstdc
++ -o libstdc++.so <object files> -lc
ld complains with:
ld: warning: cannot find entry symbol _start; defaulting to 00003004
(any many many undefined references)
So it seems it doesn't try to build a shared object file but a
executable instead? Perhaps my gcc/binutils is configured in the wrong
way?
When using ld, as described above, at least building works. But it
contains strange - at least to me - relocations:
Offset Info Type Sym.Value Sym. Name
...
0002607c 0000ec01 R_386_32 00000000
_ZTVN10__cxxabiv120__si_class_type_infoE
0002609c 0000ec01 R_386_32 00000000
_ZTVN10__cxxabiv120__si_class_type_infoE
000261dc 0000ec01 R_386_32 00000000
_ZTVN10__cxxabiv120__si_class_type_infoE
000261e8 0000ec01 R_386_32 00000000
_ZTVN10__cxxabiv120__si_class_type_infoE
...
I'm not an expert for this stuff but at least I can't find any
information about 0-values for R_386_32 in the elf-format-document and
if I look in the relocations in glibc's dynamic linker, they don't seem
to treat them special, either. The libstdc++.so on my linux-system has
no such entries as well. And, as one would expect, it doesn't work with
this value.
So my questions are:
- Can it actually happen that symbols relocated as R_386_32 have a value
of 0 (and should be treaten special by the dynamic linker)?
- If not, has anybody an idea what may cause ld to generate them?
- Or is the reason, that I'm using ld instead of g++? If so, what may be
the reason that g++ tries to build an executable instead of a shared
library?
Thanks in advance!
Nils Asmussen