bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Michael Hudson-Doyle <michael.hudson@canonical.com>
Cc: bug-gnulib@gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org
Subject: Re: Undefined use of weak symbols in gnulib
Date: Mon, 12 Jul 2021 17:03:40 +0200	[thread overview]
Message-ID: <87y2ab8tgz.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAJ8wqtfX2yn721W=hKZTByxBRRPxxGDLOEw8t6+6rfQUb3oGWA@mail.gmail.com> (Michael Hudson-Doyle's message of "Mon, 12 Jul 2021 22:04:11 +1200")

* Michael Hudson-Doyle:

> Did this thread ever reach a conclusion? I'm testing a snapshot of
> glibc 2.34 in ubuntu and running into this issue -- bison segfaults on
> startup on ppc64el.

For us it got resolved with a binutils fix:

commit b293661219c36e72acb80502a86b51160bb88cfd
Author: Alan Modra <amodra@gmail.com>
Date:   Mon May 3 10:03:06 2021 +0930

    PPC: ensure_undef_dynamic on weak undef only in plt
    
    It's slightly weird to have a call to a weak function not protected by
    a test of that function being non-NULL, but the non-NULL test might be
    covered by a test of another function.  For example:
      if (func1)
        {
          func1 ();
          func2 ();
        }
    where func2 is known to exist if func1 exists.
    
            * elf32-ppc.c (allocate_dynrelocs): Call ensure_undef_dynamic for
            weak undefined symols that only appear on PLT relocs.
            * elf64-ppc.c (allocate_dynrelocs): Likewise.

We rebuilt bison and a couple of other packages that looked like it
would be affected by this before putting glibc 2.34 snapshots into the
buildroot, and that worked quite well for us.  (Thanks to Andreas Schwab
for identifying the issue so early.)

We don't know yet whether there are user binaries out there which will
be incompatible with glibc 2.34.  I have posted a glibc patch which
alters symbol resolution to increase compatibility with old binaries (so
it's technically feasible to get this working again), but in the review
discussion, I was asked to break *more* older binaries, including every
i386 binary from the late 1990s/early 2000s, so I dropped that patch and
did not pursue this approach further.  But I guess we can get back to it
if feedback from end users indicates that the current approach doesn't
work for them.

Thanks,
Florian



  reply	other threads:[~2021-07-12 15:07 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-27  5:53 Undefined use of weak symbols in gnulib Florian Weimer
2021-04-27  6:50 ` Paul Eggert
2021-04-27  6:58   ` Florian Weimer
2021-04-27  7:13     ` Paul Eggert
2021-04-27  7:24 ` Andreas Schwab
2021-04-27 11:06   ` Florian Weimer
2021-04-28  0:09     ` Bruno Haible
2021-04-28  2:10       ` H.J. Lu
2021-04-28  2:13         ` H.J. Lu
2021-05-05 20:31           ` Fangrui Song
2021-04-28  8:35         ` Florian Weimer
2021-04-28 13:15           ` Michael Matz
2021-04-28  7:44       ` Florian Weimer
2021-04-28 14:48         ` Bruno Haible
2021-04-28 17:44           ` Florian Weimer
2021-07-17 14:38         ` Bruno Haible
2021-07-17 14:55           ` Florian Weimer
2021-07-17 16:39             ` Bruno Haible
2021-07-27 20:02           ` Joseph Myers
2021-07-27 20:19             ` Florian Weimer
2021-07-27 23:38               ` Paul Eggert
2021-07-17 16:21         ` Bruno Haible
2021-04-27 23:22   ` Bruno Haible
2021-04-27 23:47 ` Bruno Haible
2021-04-28  7:57   ` Florian Weimer
2021-04-28 14:40     ` Bruno Haible
2021-04-28 17:43       ` Florian Weimer
2021-04-29 15:15         ` Bruno Haible
2021-04-30  9:55           ` Florian Weimer
2021-04-29  6:33       ` Ben Pfaff
2021-05-03  1:44 ` Alan Modra
2021-07-12 10:04 ` Michael Hudson-Doyle
2021-07-12 15:03   ` Florian Weimer [this message]
2021-07-12 15:30     ` Matthias Klose
2021-07-12 15:37       ` Florian Weimer
2021-07-13  0:22         ` Michael Hudson-Doyle

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=87y2ab8tgz.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=bug-gnulib@gnu.org \
    --cc=libc-alpha@sourceware.org \
    --cc=michael.hudson@canonical.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).