Re: Dynamic Linkage Problem

Re: Dynamic Linkage Problem

[Bret Orsburn]

egcs group:

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
0000000000440218 JMP_SLOT         
remove__t8OBFixSeq1ZQ215OBSelectReactor11HandlerInfoUi
0000000000440220 JMP_SLOT          _OB_narrowHelp__C16OCI_AcceptorInfoPCc
0000000000440228 JMP_SLOT          _OB_destroy__26OCI_IIOP_AcceptorInfo_impl
0000000000440238 JMP_SLOT         
_duplicate__26OBGIOPClientWorkerReactiveP26OBGIOPClientWorkerReactive
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
the rest.

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.)

----

	Bret Orsburn
	borsburn@codonics.com

Re: Dynamic Linkage Problem

[H.J. Lu]

> 
> egcs group:
> 
> 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).
> 

Please try binutils 2.9.1.0.13 which I just announced.

H.J.

Re: Dynamic Linkage Problem

[Richard Henderson]

On Fri, Sep 18, 1998 at 10:12:18AM -0400, Bret Orsburn wrote:
> (Dynamic linkage of a very large library under RedHat Alpha Linux 5.1 +
> egcs-1.1b + glibc-2.0.7-19).

Yep, a binutils bug fixed day before yesterday.  The problem being
that there were missing RELATIVE dynamic relocations for the secondary
.got.plt entries that get created when the initial .got subsegment 
gets too big.

H.J. put out a new binutils minor release containing the fix.


r~

Re: Dynamic Linkage Problem

[Uncle George]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

while ur at it
    can u ( if u havent allready ) fix a LD bug related to the alpha. the
.dynsym section should be cleared out on the alpha before use. Some entries
in the  table are not cleared when the table becomes populated, and random
numbers are left within the table. An example would be the libdl.so
distributed with the 6cd jewel set. It has bogus entries that causes gdb to
go core.
I had posted this patch before, but dont know what happened to it - if
anything.

in bfd/elflink.h @ 2733 u should use a zmalloc

      /* Set the size of the .dynsym and .hash sections.  We counted
  the number of dynamic symbols in elf_link_add_object_symbols.
  We will build the contents of .dynsym and .hash when we build
  the final symbol table, because until then we do not know the
  correct value to give the symbols.  We built the .dynstr
  section as we went along in elf_link_add_object_symbols.  */
      s = bfd_get_section_by_name (dynobj, ".dynsym");
      BFD_ASSERT (s != NULL);
      s->_raw_size = dynsymcount * sizeof (Elf_External_Sym);
      s->contents = (bfd_byte *) bfd_zalloc (output_bfd, s->_raw_size); /*
[gb] */
/* memset( s->contents, 0xff, s->_raw_size); */    /* [gb] insure corruption
*/
      if (s->contents == NULL && s->_raw_size != 0)
 return false;

      /* The first entry in .dynsym is a dummy symbol.  */


Richard Henderson wrote:

> On Fri, Sep 18, 1998 at 10:12:18AM -0400, Bret Orsburn wrote:
> > (Dynamic linkage of a very large library under RedHat Alpha Linux 5.1 +
> > egcs-1.1b + glibc-2.0.7-19).
>
> Yep, a binutils bug fixed day before yesterday.  The problem being
> that there were missing RELATIVE dynamic relocations for the secondary
> .got.plt entries that get created when the initial .got subsegment
> gets too big.
>
> H.J. put out a new binutils minor release containing the fix.



[-- Attachment #2: b.txt --]
[-- Type: text/plain, Size: 1096 bytes --]

Subject: Re: striped shared ELF lib & GDB
Date: Wed, 17 Jun 1998 17:23:08 -0400
From: Uncle George <gatgul@voicenet.com>
Organization: None Avail
To: bug-gnu-utils@gnu.org
CC: "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de>,
     "axp-list@redhat.com" <axp-list@redhat.com>,
     "Jay.Estabrook@digital.com" <Jay.Estabrook@digital.com>

for the alpha/redhat/5.0 with ld 2.9.1 there is a problem with clearing out the
.dynsym table. IT JUST ISN'T DONE. what ever is left over in the memory allocated
by bfd_alloc() elflink.h:2564 is ( on occasion used, by virtue of it not being
cleared ) as a bogus dynsym entry. Later on when the table is finally populated ,
any skipped entries ( done by elf64_alpha_finish_dynamic_sections() ) will not
have been zeroed!

ergo change the bfd_alloc() to bfd_zalloc()  @ elflink.h:2564.

this will make my gdb happy, objdump happy as can be.
gat

Peter.Schauer wrote:

> This looks more like a linker problem, although GDB shouldn't dump core.
> Unfortunately I don't have access to alpha Linux, but I could try to
> re

Re: Dynamic Linkage Problem

[Richard Henderson]

On Sat, Sep 19, 1998 at 11:31:29AM -0400, Uncle George wrote:
>     can u ( if u havent allready ) fix a LD bug related to the alpha. the
> .dynsym section should be cleared out on the alpha before use. Some entries
> in the  table are not cleared when the table becomes populated, and random
> numbers are left within the table. An example would be the libdl.so
> distributed with the 6cd jewel set. It has bogus entries that causes gdb to
> go core.
> I had posted this patch before, but dont know what happened to it - if
> anything.

Can you still replicate this?  Some time ago I thought the real cause
had been fixed, in not allocating too much space to begin with.


r~

Re: Dynamic Linkage Problem

[H.J. Lu]

> 
> This is a multi-part message in MIME format.
> --------------BE666905CE35FAB88D17BE66
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> while ur at it
>     can u ( if u havent allready ) fix a LD bug related to the alpha. the
> .dynsym section should be cleared out on the alpha before use. Some entries
> in the  table are not cleared when the table becomes populated, and random
> numbers are left within the table. An example would be the libdl.so
> distributed with the 6cd jewel set. It has bogus entries that causes gdb to
> go core.
> I had posted this patch before, but dont know what happened to it - if
> anything.
> 

From bfd/ChangeLog.linux in binutils 2.9.1.0.13:

Sun Aug  9 11:52:47 1998  H.J. Lu  (hjl@gnu.org)
       
        * elf32-arm.c (elf_arm_size_dynamic_sections): Use bfd_zalloc
        instead of bfd_alloc for allocating the section contents.
        * elf32-i386.c (elf_i386_size_dynamic_sections): Likewise.
        * elf32-m68k.c (elf_m68k_size_dynamic_sections): Likewise.
        * elf32-mips.c (mips_elf_size_dynamic_sections): Likewise.
        * elf32-sparc.c (elf32_sparc_size_dynamic_sections): Likewise.
        * elf64-alpha.c (elf64_alpha_do_reloc_gpdisp): Likewise.
        * elf64-mips.c (mips_elf64_write_relocs): Likewise.
        * elfcode.h (write_relocs): Likewise.
        * elflink.h (NAME(bfd_elf,size_dynamic_sections)): Likewise.
        (NAME(bfd_elf,size_dynamic_sections)): Likewise.
        (NAME(bfd_elf,size_dynamic_sections)): Likewise.
        (elf_bfd_final_link): Likewise.

Is that good enough for you?


H.J.

Re: Dynamic Linkage Problem

[Bret Orsburn]

Thanks for your help with this problem.

Another win for Open Source!

----

	Bret Orsburn
	borsburn@codonics.com

Dynamic Linkage Problem

[Bret Orsburn]

egcs group:

I'm unable to build ORBacus 3.0 (ref. http://www.ooc.com/ob/ ) with shared libs
with egcs-1.0.2 or egcs-1.1b under Redhat Alpha Linux 5.0 or 5.1 (and
glibc-2.0.7-19).

The build fails when testing the idl translator. The idl translator segment
faults.

I've observed some of the runtime dynamic linkage process under gdb. I've gotten
as far as watching the runtime linker leave many un-relocated slots in the .got
of libOB.so. On execution, the code tries to jump to the unrelocated offset,
which is an illegal address in low memory.

The idl program appears to work (and a cursory examination reveals no
un-relocated .got entries) when libOB.so is arbitrarily partitioned into two
smaller libs (libOB.so is quite large).

I'm trying to work through the problem but this is unfamiliar territory for me
and my progress is quite slow.

The problem appears to be size-related, so the prospects of providing a small
test case are not good.

Thanks for any help or pointers you can provide.

----

	Bret Orsburn
	borsburn@codonics.com