This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Binutils <binutils at sourceware dot org>
- Date: Wed, 24 Feb 2016 08:41:38 -0800
- 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> <alpine dot LSU dot 2 dot 20 dot 1602241709410 dot 20277 at wotan dot suse dot de>
On Wed, Feb 24, 2016 at 8:14 AM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> 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.
Ld makes no such guarantee. When you link .o files compiled with
non-PIC together with an archive compiled with -fPIC, you may get an
executable whose behavior is unpredictable.
>> > 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
> broken.
>
>> > 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?
>
My change will make ld guarantees the consistent behavior, regardless PIC
or non-PIC.
--
H.J.