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: 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 16:25:36 +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>
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:
>
> 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
_not_ to also break PIC code, you'd actively break programs that work
right now.
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
segfaults.
The patch _does_ break the currently working PIC example, though. I don't
think that's an improvement over the status quo.
> > 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?
Ciao,
Michael.