Biutils compatilibility breakage in 2.24 for PPC

Biutils compatilibility breakage in 2.24 for PPC

[alexandru.sardan]

Hello,

While trying to link the kernel with the latest binutils (2.24) I get the following errors:

| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:505:(.text+0x151b2): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:506:(.text+0x151c6): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
| arch/powerpc/kernel/built-in.o: In function `exc_debug_debug_book3e':
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:571:(.text+0x1537e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:572:(.text+0x15392): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_end_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
| arch/powerpc/kernel/built-in.o: In function `skpinv':
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:1110:(.text+0x16156): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+16170
| arch/powerpc/kernel/built-in.o: In function `a2_tlbinit_after_linear_map':
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:1176:(.text+0x161f6): relocation truncated to fit: R_PPC64_ADDR16_HI against `.text'+16204
| arch/powerpc/kernel/built-in.o: In function `.init_core_book3e':
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:1365:(.text+0x16312): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `interrupt_base_book3e' defined in .text section in arch/powerpc/kernel/built-in.o
| arch/powerpc/kernel/built-in.o: In function `.fsl_enable_threads':
| /local/workspace/yocto-sdk-build/master/p5040ds-64b/linux/arch/powerpc/kernel/exceptions-64e.S:1394:(.text+0x1636e): relocation truncated to fit: R_PPC64_ADDR16_HI against symbol `.fsl_secondary_thread_init' defined in .text section in arch/powerpc/kernel/head_64.o

This is caused by this patch [1] that changed the behavior of @h and @ha that are currently used by the kernel.
Is there any plan to revert this in the future and maybe introduce another modifier that does the desired job?

Thanks,
Alex


[1] https://sourceware.org/ml/binutils/2013-10/msg00372.html

Re: Biutils compatilibility breakage in 2.24 for PPC

[Alan Modra]

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.

> and maybe introduce another modifier that does the desired job?

Already available.  @high and @higha

-- 
Alan Modra
Australia Development Lab, IBM

Re: Biutils compatilibility breakage in 2.24 for PPC

[Scott Wood]

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.

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

-Scott

Re: Biutils compatilibility breakage in 2.24 for PPC

[Alan Modra]

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.

> > > 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
gcc-testresults@gcc.gnu.org!  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
@ha.

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

Re: Biutils compatilibility breakage in 2.24 for PPC

[Scott Wood]

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

Re: Biutils compatilibility breakage in 2.24 for PPC

[Alan Modra]

On Wed, Apr 09, 2014 at 10:53:51PM -0500, Scott Wood wrote:
> 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.

You won't change my mind.  I quite clearly pointed out that I was
fixing an ABI hole, that will benefit large user apps.  The fact that
it breaks your booke kernel is unfortunate but unavoidable if we want
to keep the (changed) ABI consistent.

-- 
Alan Modra
Australia Development Lab, IBM

Re: Biutils compatilibility breakage in 2.24 for PPC

[Sebastian Huber]

On 2014-04-10 05:53, Scott Wood wrote:
>> 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.:-(
>

Freescale has a tool chain team for the FSF versions?  It would be nice if they 
could so some automatic testing to avoid problems like this:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60102

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Biutils compatilibility breakage in 2.24 for PPC

[Joseph S. Myers]

On Wed, 9 Apr 2014, Scott Wood wrote:

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

At one point there was a suggestion of the Power.org ABI TSC working on 
the 64-bit ABI.  But the last time I tried to contact the TSC, my message 
didn't get through - and I didn't hear anything back from 
postmaster@power.org either when I contacted them about the problems with 
the powerabi@power.org list.  Perhaps Freescale has contacts at Power.org 
that you can use to get them to get the ABI mailing list in working order 
again?

-- 
Joseph S. Myers
joseph@codesourcery.com