Re: R_386_32 relocations with sym-value=0 ?

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

> The zero entry is normally added by crtendS.o, which gcc normally links
> in automatically for a shared library.
Ahh, thanks! I've now reconfigured my gcc so that it also generates the
crtbeginS.o and crtendS.o. Additionally my dynamic linker does not
locate the .ctors-section anymore to call the global constructors, but
instead calls the function in the .init-section (which calls frame_dummy
and __do_global_ctors_aux). That means also, that frame_dummy registers
the exception-frames now, not my dynamic linker.
I guess, thats the intended way. At least its a very clear way, IMO :)

(Thats also the reason why I try this approach instead of changing the
#if in gcc's unwind-dw2-fde-glibc.c. I think its more clearly and, most
important, does not require gcc-changes)

Unfortunatly, it still does not work. I have the same problem as before:
The unwind-routines do not find the catch-handler, which leads to
calling the terminate-function. My guess is that the - still present -
"strange" relocations cause it. Because the function get_adjusted_ptr()
of gcc, which is called during unwind, references the symbol
_ZTVN10__cxxabiv120__si_class_type_infoE. readelf lists the following
relocation for that symbol:
 Offset     Info    Type            Sym.Value  Sym. Name
0001a06c  00009301 R_386_32          00000000   _ZTVN10__cxxabiv120__s

I guess, that can't be correct. Because it would mean that its placed at
the beginning of the shared library, i.e. the ELF-header.
As I mentioned in a previous mail, I can at least prevent a page-fault
(caused by using this senseless memory-location) by resolving the symbol
(found in the executable) and using that value instead. But I doubt that
this is correct because, as Alan Modra said before, a zero-value has no
special meaning.
Additionally, when I look at the relocations in the libstdc++.so of my
linux-system, this symbol has a non-zero-value.

Now I build my libstdc++.so by the following command:
g++ -nodefaultlibs -shared -Wl,-shared -Wl,-soname,libstdc++.so -o
libstdc++.so <object files> -lc

If someone remembers, my last way was to use ld instead of g++. Now I
figured out that it works fine with g++ when I pass -shared to gcc AND
ld. Probably my gcc is configured in the wrong way, causing gcc to not
pass -shared to ld. But that should be independent of the current
problem :)
At least, except for the strange relocations, the generated libstdc++.so
looks correct and works (without exceptions).

Does anybody know whats wrong here?

Nils Asmussen