This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- From: Michael Matz <matz at suse dot de>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 24 Feb 2016 17:14:33 +0100 (CET)
- Subject: Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- Authentication-results: sourceware.org; auth=none
- References: <20160223175814 dot GA2858 at intel dot com> <alpine dot LSU dot 2 dot 20 dot 1602241541430 dot 20277 at wotan dot suse dot de> <CAMe9rOoxU43=dhGYZZGQtWhfbU-sGRoaiiJ7PfPNtzSc05-t-A at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1602241552020 dot 20277 at wotan dot suse dot de> <CAMe9rOpEWKVVP=-o0t0emkjKR0-xqnn-YZ5C5nfa=0E4BkEZaw at mail dot gmail dot com>
On Wed, 24 Feb 2016, H.J. Lu wrote:
> >> It never worked correctly:
> >> https://sourceware.org/bugzilla/show_bug.cgi?id=19719
> > That's using non-PIC code to show the problem with it, sure, we
> > already knew that it doesn't work correctly with non-PIC. The fix to
> > that is
> I won't calling it working for 20+ years "doesn't work correctly". In my
> opinion, PIC is an odd one out.
No, non-PIC is the wrong one IMO (because such checking at runtime is one
of the points of weak symbols). And whatever we might think about this,
there's code in the wild that assumes weak symbols work like they do right
now (and that code knows that it has to use PIC code for that). It's
simply no option to break that now.
> > _not_ to also break PIC code, you'd actively break programs that work
> > right now.
> We should make PIC and non-PIC behave the same.
Not at the expense of breaking working code.
> > The patch _does_ break the currently working PIC example, though. I
> > don't think that's an improvement over the status quo.
> My testcase shows otherwise.
Your testcase shows that non-PIC code is broken, not that PIC code is
> > Well, as you say, that has interesting consequences we'd want to
> > ponder. Why rushing in stuff that breaks programs?
> It is in the same boat as LD_DYNAMIC_WEAK in ld.so. If one wants the old
> behavior, use -z dynamic-undefined-weak.
That doesn't make sense to me. Why should one suddenly have to use an
option to get useful behaviour that one got since about forever before?