Re: Biutils compatilibility breakage in 2.24 for PPC

[Scott Wood <scottwood at freescale dot com>]

On Thu, 2014-04-10 at 11:55 +0930, Alan Modra wrote:
> 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, alexandru.sardan@freescale.com 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.

Does binutils usually change established ABIs like that?  "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" says "#hi(x) =
((x >> 16) & 0xffff)", not "#hi(x) = (x >> 16)".

Is there a newer version of the ELFv1 document that makes this change,
or is this just going to be an undocumented quirk?  Is encouraging
adoption of ELFv2 not adequate to deal with the overflow problem?  For
that matter, where is ELFv2 documented?

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

If I'm going to introduce such a hack to the kernel I want to be able to
clearly point to why it was needed, and why fixing the toolchain isn't
an option.

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

Sure.  I'm pointing out that this is behavior, specified by an ABI
document, that is supposed to be stable -- in the hopes that it will
change your mind, or attract the attention of other binutils developers
who find this problematic.  If it doesn't, then so be it.

> When was the last time Freescale contributed anything to
> binutils or gcc?  I don't even see simple things like reports on
> gcc-testresults@gcc.gnu.org!

As someone whose time is full with the kernel and other things, all I
can do is share your frustration, and forward this to our toolchain
people. :-(

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

FWIW, this was reported to our toolchain people a couple months ago, and
they apparently did nothing with the report until I pinged them about
it.

If this were the kernel I wouldn't be able to get away with breaking an
ABI just because a few months go by before it's noticed... especially
when the people affected are users rather than others developing the
same project.  I can't follow every mailing list in the world.  I have
enough trouble following all the relevant high volume kernel lists. :-P

> 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
> @ha.
> 
> I'll happily review such a binutils patch, but right at the moment I'm
> disinclined to write it myself.

Alexandru, is this something we could do?  It sounds a bit hacky
though...

-Scott