This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR ld/19636: [x86] Resolve undefweak and defined symbols in executable

On Wed, Feb 24, 2016 at 7:25 AM, Michael Matz <> wrote:
> Hi,
> 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 in the first ln -sf call), it still
> segfaults.

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 If one wants
the old behavior, use  -z dynamic-undefined-weak.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]