This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: R_386_32 relocations with sym-value=0 ?
Nils Asmussen <nils@script-solution.de> writes:
> build with:
> g++ -fPIC -c -o myex.o myex.cpp
> ld -shared -soname libtest.so -o libtest.so myex.o
> g++ -fPIC -c -o test.o test.cpp
> g++ -nodefaultlibs -o test test.o -lgcc_s -lsupc++ -lc -L. -ltest
>
> When I run the application I get:
>> terminate called after throwing an instance of 'myexception'
>> Aborted
> (which is the behaviour I'm experiencing with my OS atm, too. Although I
> have to threat the zero-symbol special by searching for the symbol and
> using that value to prevent other problems. But thats perhaps a different
> story, I don't know...)
> Note in the last g++-command, that I try to use the same stuff like
> when doing that for my OS. So, just libc, libgcc (actually I'm using the
> static one for my OS, but I think that shouldn't matter) and libsupc++.
>
> If I instead use g++ to link libtest.so:
> g++ -shared -Wl,-soname,libtest.so -o libtest.so myex.o -nostdlib
> Everything works fine:
>> Exception caught
This suggests to me that you are using a linker which does not support
--eh-frame-hdr, or your compiler has been configured to not pass that
option to the linker (normally gcc will pass the option if the linker
supports it).
If your linker does not support --eh-frame-hdr, then exception frames
must be explicitly registered at program startup time. If they are not,
exceptions can not unwind the stack. When the linker does support
--eh-frame-hdr, the linker creates a PT_GNU_EH_FRAME program segment
which lists the exception frames, and the runtime support uses
dl_iterate_phdr to find it.
Ian