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: Biutils compatilibility breakage in 2.24 for PPC

On Wed, Apr 09, 2014 at 04:02:45PM -0500, Scott Wood wrote:
> On Wed, Apr 09, 2014 at 11:49:49PM +0930, Alan Modra wrote:
> > On Wed, Apr 09, 2014 at 01:54:42PM +0000, wrote:
> > > Is there any plan to revert this in the future
> > 
> > Nope.  The great majority of ppc64 code benefits from having @h and
> > @ha report 32-bit signed overflow, rather than silently overflowing at
> > runtime.
> You could have introduced new overflow checking variants instead of
> breaking backwards compatibility, or added a flag to enable such
> checking.

I went down that path first, and decided against it, because the
change is really fixing a hole in the ABI.  We want nearly all uses of
@h and @ha, and their associated relocations, to report 32-bit signed
overflow and to do so by default.  In particular, linking old object
files with a new linker should report an overflow.  That precludes
adding new relocations for the new overflow semantics.  We want the
*old* relocations to report overflows.  This is not just for the ELFv2
ABI, but the ELFv1 ABI also needs this.  For example with gcc's
-mcmodel=medium code it's possible for an offset from the toc pointer
to some data to be more than 2G.  It is much better to find this at
link time rather than run time.  I'll admit that it would have been
possible to fix practically all of these holes without changing the
ADDR16_HI and ADDR16_HA relocs, but then we'd have context sensitive
@h and @ha.

> > > and maybe introduce another modifier that does the desired job?
> > 
> > Already available.  @high and @higha
> If we use these, then the code will not build on older binutils.  If this
> compatibility breakage remains, we'll have to test the binutils version
> and do some sort of ifdef based on it.  Not nice.

Kernel people are clever, or so they keep telling us.  Shouldn't be a
big problem..

I don't know how to say this without being harsh, but the fact is that
the people who contribute to open source are the people who have the
say.  When was the last time Freescale contributed anything to
binutils or gcc?  I don't even see simple things like reports on!  And it speaks volumes about the level of
Freescale contribution that you're only finding this problem in the
kernel now, over 5 months since the binutils change was made, and over
4 months since binutils-2.24 was released.  The time to comment was
when I posted the change.

Here is what you can do now.  You can either make the kernel changes
necessary to work with new and old binutils.  Think of this as me
contributing to your job security. :)  Or you can modify binutils to
implement the context sensitive @h and @ha.  I actually started doing
that along with the change to reloc behaviour, but it turned out a
little messy.  Without a known failure case, I decided it wasn't worth
the bother.  The basic idea is to take note of expressions used with
@highest and @higher, and if the same expression appears on @h convert
the @h to @high internally.  Similarly for @highesta, @highera and

I'll happily review such a binutils patch, but right at the moment I'm
disinclined to write it myself.

Alan Modra
Australia Development Lab, IBM

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