This is the mail archive of the
mailing list for the GCC project.
Re: Dynamic Linkage Problem
- To: egcs at cygnus dot com
- Subject: Re: Dynamic Linkage Problem
- From: borsburn at codonics dot com (Bret Orsburn)
- Date: Fri, 18 Sep 1998 10:12:18 -0400
- CC: axp-list at redhat dot com
- Organization: Codonics, Inc.
More details about this problem:
(Dynamic linkage of a very large library under RedHat Alpha Linux 5.1 +
egcs-1.1b + glibc-2.0.7-19).
There appear to be two different species of JMP_SLOT relocation records in the
.so file. Here is an example:
0000000000440208 JMP_SLOT _OB_destroy__27OCI_IIOP_ConnectorInfo_impl
0000000000440210 JMP_SLOT _$_22OCI_IIOP_TransportInfo
0000000000440220 JMP_SLOT _OB_narrowHelp__C16OCI_AcceptorInfoPCc
0000000000440228 JMP_SLOT _OB_destroy__26OCI_IIOP_AcceptorInfo_impl
000000000044e9e8 JMP_SLOT __get_eh_context
0000000000440248 JMP_SLOT kind__C14CORBA_TypeCode
0000000000440258 JMP_SLOT accept
0000000000440268 JMP_SLOT __12OBGIOPServerP12OCI_Acceptor
0000000000440270 JMP_SLOT _timeout__12CORBA_Object
0000000000440278 JMP_SLOT OBGetInAddr__FPCcR11sockaddr_in
0000000000440280 JMP_SLOT OBMarshalCountMulti__FPCsRUiUi
Note that the offset for __get_eh_context is out of sequence.
Out of the 1135 JMP_SLOT relocation records in the .so file, 70 of them, salted
throughout the list, form a separate sequence at a somewhat higher offset than
When the code executes, it tries to jump to the .got address at offset 0x440240,
which should be the entry for __get_eh_context. Instead, this address contains
an unrelocated offset.
In short, there is a disagreement between the code and the relocation records as
to which .got slots correspond to which function. (The code references are
relative to gp, so tracing the problem further requires more knowledge than I
possess about how gp is managed.)