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, 24 Feb 2016, H.J. Lu wrote:

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

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 

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

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?


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