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

Geoff's gmon_start fix to binutil works! (fwd)

Am I correct in thinking that this is needed for woody?

If so, let me know and I'll make a new binutils upload with it included...


---------- Forwarded message ----------
Date: Sat, 14 Oct 2000 15:57:42 -0700 (PDT)
From: Jack Howarth <howarth@bromo.med.uc.edu>
To: libc-alpha@sourceware.cygnus.com
Subject: Geoff's gmon_start fix to binutil works!

    I just rebuilt and installed binutils with Geoff's proposed patch
 to elf32ppc.c I then rebuilt glibc 2.1.95 WITHOUT Franz's hack to
    The rebuilt glibc passed make check with no problems. I then repeated
my original test of installing a zlib built under glibc 2.1.3 on my machine,
rebuilding the zlib example linking against that zlib and glibc 2.1.95.
Afterwards I rebuilt zlib against glibc 2.1.95 with the new patched binutils
and installed this glibc 2.1.95-built zlib. The previous problem is now fixed.
There are no segfaults when running a hybrid binary (linked against
glibc 2.1.95 and a glibc 2.1.3-built lib) under linuxppc now. Please do not
use Franz's hack to sysdeps/generic/initfini.c. The only problem I see
now is that HJ is out for a couple weeks so we may not get an offical
release from him of binutils with Geoff's patch. However if Geoff has
it already in the binutils cvs you could just note that ppc requires
a release later than since I am sure the next release will
have Geoff's patch whatever it is numbered.

===File ~/patches/cygnus/glibc-ld-weakplt.patch=============
2000-10-14  Geoffrey Keating  <geoffk@shoggoth.cygnus.com>

        * elf32-ppc.c (ppc_elf_finish_dynamic_symbol): Don't make PLT
        entries that could serve as a definition for a weak symbol.

Index: elf32-ppc.c
RCS file: /cvs/cvsfiles/devo/bfd/elf32-ppc.c,v
retrieving revision 1.105
diff -u -p -r1.105 elf32-ppc.c
--- elf32-ppc.c 2000/07/29 20:23:09     1.105
+++ elf32-ppc.c 2000/10/14 20:46:57
@@ -1715,7 +1716,8 @@ ppc_elf_adjust_dynamic_symbol (info, h)

             2. We know for certain that a symbol is defined in
             this object, because this object is the application,
-            is linked with -Bsymbolic, or because the symbol is local.
+            is linked with -Bsymbolic, the symbol is local,
+            or because the symbol is protected or hidden.

             3. GC has rendered the entry unused.
             Note, however, that in an executable all references to the
@@ -2675,6 +2677,13 @@ ppc_elf_finish_dynamic_symbol (output_bf
          /* Mark the symbol as undefined, rather than as defined in
             the .plt section.  Leave the value alone.  */
          sym->st_shndx = SHN_UNDEF;
+         /* If the symbol is weak, we do need to clear the value.
+            Otherwise, the PLT entry would provide a definition for
+            the symbol even if the symbol wasn't defined anywhere,
+            and so the symbol would never be NULL.  */
+         if ((h->elf_link_hash_flags & ELF_LINK_HASH_REF_REGULAR_NONWEAK)
+             == 0)
+           sym->st_value = 0;


Reply to: