Bug 1300543

The new 7.3 binutils is based upon the F23 binutils, so changing this BZ to MODIFIED so that QE can test/verify.

I tried building sipp using binutils-2.25.1-1.el7, but I get the same errors as before.  Do I need to try a different (or later) version?

Hi Guys,

  I am reverting this BZ to assigned, since upgrading the binutils sources does not fix the problem.

  I have started an email thread about the problem on the binutils mailing list:

https://www.sourceware.org/ml/binutils/2016-02/msg00119.html

  Essentially it boils down to a test case like this:

file1.c:  extern int foo; int a (void) { return foo; }
file2.c:  char bar, foo, baz;

  When the function a() in file1,c tries to access the variable foo, it uses a 32-bit wide, 32-bit aligned access.  This fails because foo is actually 8-bits wide and 8-bit aligned, and, as it happens, not placed on a 32-bit aligned boundary.

  So the linker is correct in refusing the link the program, but it certainly could produce a more helpful error message.  I have created a patch to do this, which can be found in the email thread above.  If it proves to be acceptable I will backport it to the RHEL sources.

  The reason that this problem arises on the AArch64 architecture and not on other architectures is that the AArch64 has stricter alignment requirements on its load and store instructions.  In particular a 32-bit access will not encode the bottom two bits of the address to be accessed, so the address *must* be on a 32-bit boundary.  Other architectures may end up with slower accesses, or a run-time failure, but not a link time failure.

Since the same version of sipp builds for F23, 

  http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=327954

I tried another build in RHELSA using the F23 version of binutils (binaries straight from koji, without rebuilding it for RHELSA):

  http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=318616

but I still get the same error as before, so I'm trying to determine why it successfully builds for AArch64 on F23, and fails on RHELSA-7.2.

I can reproduce this on a local build system; succeeds in F23 mock chroot, fails in RHELSA-7.2 mock chroot, even if using the F23 binutils.

Could the issue be that some of the options used (flags for the compiler or linker) differ between F23 and RHELSA, or possibly a difference in the code the compiler generates for the linker?

> Could the issue be that some of the options used (flags for the compiler or
> linker) differ between F23 and RHELSA, or possibly a difference in the code
> the compiler generates for the linker?

Yes.  Also another possibility is that the *placement* of the variables into the .data or .bss sections differs between the two installations.  This matters because the linker will only detect a problem if the code tries to make an unaligned access to the variable.  In the code example in comment #3, if you remove the declaration of the bar and baz variables the code will compile and link without any problems, because foo, even though it only needs byte alignment, will just happen to be placed onto a word aligned boundary.  (The compiled code will still be incorrect however.  Function a will still be loading foo as if it were a 32-bit quantity and not an 8-bit quantity).

Created attachment 1122382 [details]
Better warning message about overflown relocs

This is the patch that I plan to check in to the RHEL 7.3 binutils, once they are
open for new fixes.

Verified for build binutils-2.25.1-20.base.el7 - ld refuses to link the binary - which the expected behavior, as per #c3 - but provides more descriptive message.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2265.html