Re: PPC64 GOT alignment trouble

[Alan Modra <amodra at gmail dot com>]

On Thu, Oct 15, 2015 at 12:31:30PM +0100, Andrew Stubbs wrote:
> On 15/10/15 10:48, Andrew Stubbs wrote:
> >Is this breakage unintentional? Was it supposed to continue to work when
> >not 256-byte aligned?
> >
> >It needs to either Just Work, or fail with a useful diagnostic, but I
> >don't know which?
> 
> I'm still not clear whether it was supposed to realign the section
> automatically?

The section isn't realigned automatically.  What happens is that the
TOC base changes.  ie. We don't have r2 pointing at the .got output
section plus 0x8000.

But, that might happen for other reasons.  For example, some future ld
optimisation might detect that no object file is small model and thus
the magic ".got + 0x8000" is no longer needed to suit r2 plus signed
16-bit offset addressing.  Instead, ld might choose a value that would
allow the ELFv2 global entry code to be one less instruction in a
fixed position executable.

Really, the problem is the kernel's assumption that ".got + 0x8000" is
the value to load into r2.  Rather than defining

	__toc_start = .;

at the start of .got, and then using __toc_start + 0x8000 in code
elsewhere, it would be better to use something like

	__toc_ptr = DEFINED (.TOC.) ? .TOC. : ADDR (.got) + 0x8000;

That puts the "+ 0x8000" in one place, and newer linkers that define
.TOC. as a normal symbol will automatically use the correct value
should ld decide to change the toc base.

> Anyway, in the meantime, this warning would have made my life much easier.
> 
> OK to commit?

Not as it is.  I'm a little worried that the warning will trigger when
it shouldn't, and the patch looks to be a bit of a rush job (testing
adjust != 0 is better and it would also be better to use
TOC_BASE_ALIGN in the warning message rather than hard coding 256).
BTW, I'm on vacation tomorrow (huh, today, it's well past midnight),
so probably will be "ignoring" you until Monday.

-- 
Alan Modra
Australia Development Lab, IBM