R_386_32 relocations with sym-value=0 ?

[Nils Asmussen <nils at script-solution dot de>]

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