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

[Michael Matz <matz at suse dot de>]

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.

> > 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?


Ciao,
Michael.