[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[jakub@redhat.com: Re: [PATCH] Bug-compatibility with Sol* ld.so]



We should make sure to pick up the glibc patch that Jakub is talking
about here; presumably it will be in 2.3, but this is something to keep
in mind if there is another 2.2 release.  Which there needs to be,
since I promised to do it last weekend and didn't have time.

This only affects if glibc is _built_ with a newer version of binutils
than currently in the archive; that is, it's not a problem for
built applications.


----- Forwarded message from Jakub Jelinek <jakub@redhat.com> -----

Date: Tue, 24 Sep 2002 12:13:34 -0400
From: Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] Bug-compatibility with Sol* ld.so
To: binutils@sources.redhat.com
Reply-To: Jakub Jelinek <jakub@redhat.com>

On Tue, Sep 24, 2002 at 12:09:39PM -0400, Daniel Jacobowitz wrote:
> On Tue, Sep 24, 2002 at 05:58:11PM +0200, Jakub Jelinek wrote:
> > Hi!
> > 
> > Here is the patch I've just commited. It passed make check and
> > manual inspection with -Bsymbolic seemed ok too.
> > Had to change glibc which relied on this and will have to change prelink, argh.
> 
> How affected is glibc?  I.E. will using the new binutils break existing
> SPARC GNU/Linux installations?

Only ld.so is affected (ie. if you build glibc < CVS today with binutils
>= CVS today, ld.so will die).
It relied on the addend being in *r_offset in:
/* Return the run-time load address of the shared object.  */
static inline Elf32_Addr
elf_machine_load_address (void)
{
  register Elf32_Addr pc __asm("%o7"), pic __asm("%l7"), got;

  LOAD_PIC_REG (pic);

  /* Utilize the fact that a local .got entry will be partially
     initialized at startup awaiting its RELATIVE fixup.  */

  __asm("sethi %%hi(.Load_address),%1\n"
        ".Load_address:\n\t"
        "call 1f\n\t"
        "or %1,%%lo(.Load_address),%1\n"
        "1:\tld [%2+%1],%1"
        : "=r"(pc), "=r"(got) : "r"(pic));

  return pc - got;
}

The patch I posted today to libc-hacker doesn't rely on this and is more
robust.

	Jakub


----- End forwarded message -----

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer



Reply to: