public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Uncle George <gatgul@voicenet.com>
To: Richard Henderson <rth@cygnus.com>
Cc: Bret Orsburn <borsburn@codonics.com>, egcs@cygnus.com
Subject: Re: Dynamic Linkage Problem
Date: Sat, 19 Sep 1998 08:24:00 -0000	[thread overview]
Message-ID: <3603CE50.20257C9C@voicenet.com> (raw)
In-Reply-To: <19980918214545.B24160@dot.cygnus.com>

[-- 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

  reply	other threads:[~1998-09-19  8:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-09-18  9:44 Bret Orsburn
1998-09-18 14:46 ` H.J. Lu
1998-09-22  9:45   ` Bret Orsburn
1998-09-18 21:46 ` Richard Henderson
1998-09-19  8:24   ` Uncle George [this message]
1998-09-19 16:10     ` H.J. Lu
1998-09-19 16:10     ` Richard Henderson
  -- strict thread matches above, loose matches on Subject: below --
1998-09-15 20:44 Bret Orsburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3603CE50.20257C9C@voicenet.com \
    --to=gatgul@voicenet.com \
    --cc=borsburn@codonics.com \
    --cc=egcs@cygnus.com \
    --cc=rth@cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).