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: "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 07:44:02 -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>
On Wed, Feb 24, 2016 at 7:25 AM, Michael Matz <email@example.com> wrote:
> On Wed, 24 Feb 2016, H.J. Lu wrote:
>> >> For i386 and x86-64, undefined weak and defined symbols are resolved
>> >> without dynamic relocation when creating executable. Undefined weak
>> >> symbols aren't needed in the dynamic symbol table in executable.
>> >> One exception is on i386, we need undefined weak symbols in the
>> >> dynamic symbol table in PIE if input relocatable files contain
>> >> branchs without PLT so that we can branch to 0 with dynamic
>> >> relocation in text section.
>> > Um, wait. Have you now changed it so that this program won't work anymore
>> > (no matter if PIC or non-PIC)?:
>> It never worked correctly:
> 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.
> _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.
> Actually, I've checked with your patch, what is it supposed to do exactly?
> It certainly doesn't fix pr19719 completely: when you link edit with the
> symbol available, but then use the library not provinding the symbol at
> runtime (i.e. when you use libfun2.so in the first ln -sf call), it still
I know and will fix it.
> 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.
>> > Because, while consistence is good, it's more important that the above
>> > program keeps working (and if only under PIC).
>> I will add
>> -z dynamic-undefined-weak Treat undefined weak symbol as dynamic
>> to enable the old behavior.
> 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.