Bug 1201778

The warnings are harmless, but have been fixed upstream:

commit 0a35e3ac65dfd2db4e0ae0f68fdb21493c5fbfa1
Author: Mark Wielaard <mjw>
Date:   Fri Mar 13 23:51:40 2015 +0100

    Fix -Wimplicit warnings.

I don't understand the run-elflint-self.sh yet. The error is "correct". The _GLOBAL_OFFSET_TABLE_ does not point to the .got address. I don't know why though.

Can we have it pushed to F-22+ as it's blocking builds for aarch64

(In reply to Peter Robinson from comment #2)
> Can we have it pushed to F-22+ as it's blocking builds for aarch64

The warning fix wouldn't help. That really is a separate issue, and really only a warning, it doesn't impact the build or test suite.

We have to figure out why the _GLOBAL_OFFSET_TABLE_ symbol doesn't point to the .got. It has something to do with the new hardening flags. Without those things look fine.

Lets reassign to binutils to ask out why _GLOBAL_OFFSET_TABLE_ isn't pointing to the .got for hardened builds.

It looks like only ld.bfd is available for aarch64, otherwise you could have checked building with ld.gold to see if that linker acts the same.

If you want to work around it in the elfutils package on aarch64 for now feel free to disable the hardening build flags for aarch64 in the spec file.

Will reassign to binutils, would prefer to get it fixed properly

Hi Peter,

  Is it possible to capture how one of the broken binaries is built ?  (I could not find this in the logs).  Eg it would be really helpful to have the object files and linker command line to build, say, eu-addr2line, so that I can try to reproduce the linker's misbehaviour.  It would also be helpful if you could upload the broken binary itself (eu-addr2line) so that I can check that my local run of the linker creates the same image.

Cheers
  Nick

The relevant flags come from:
CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1'
LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld'

Where, if the aarch64 build uses the same spec files, the spec files are:

$ cat /usr/lib/rpm/redhat/redhat-hardened-cc1
*cc1_options:
+ %{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}}}}

$ cat /usr/lib/rpm/redhat/redhat-hardened-ld
*self_spec:
+ %{!shared:-pie}

*link:
+ -z now

Unfortunately I no longer have access to the aarch64 setup that I replicated it on, so I don't have the binaries anymore.

>   Is it possible to capture how one of the broken binaries is built ?  (I
> could not find this in the logs).  Eg it would be really helpful to have the
> object files and linker command line to build, say, eu-addr2line, so that I
> can try to reproduce the linker's misbehaviour.  It would also be helpful if
> you could upload the broken binary itself (eu-addr2line) so that I can check
> that my local run of the linker creates the same image.

latest builds here:
arm.koji.fedoraproject.org/koji/packageinfo?packageID=1626

Hi Peter,

(In reply to Peter Robinson from comment #7)
> latest builds here:
> arm.koji.fedoraproject.org/koji/packageinfo?packageID=1626

That does not help.  I need the object files and linker command line used to build one of the elfutils executables.  The logs only show the warnings that popped up during the build, nothing else.

What I would really like is a tarball containing the eu-addr2line executable (for aarch64 of course), plus the object files and libraries that went to make up this executable, plus the linker command line that created the executable from those object files and libraries.  Is this possible ?

Cheers
  Nick

I will provide you whole build dir.

https://hrw.fedorapeople.org/aarch64/elfutils/elfutils-0.161-6.fc23-builddir.tar.xz is whole build directory of elfutils 0.161-6.fc23 for aarch64.

Build logs inside, make was switched to not be silent so you can see how gcc/ld was called.

eu-addr2line and other tools are inside of tarball as they got built.

BTW. It seems not to depend on the specific fedora binutils and gcc version. I replicated it on another aarch64 setup with binutils-2.23.52.0.1 and gcc-4.8.3 with upstream elfutils configure with:

CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' LDFLAGS='-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' ./configure

Hi Guys,

  The problem is the -Wl,-z,relro option in LDFLAGS.  This was recently added as a global change to the Fedora build system and it is intended to make applications more secure by prevent malicious code from interfering with the run time relocations.

  Anyway the practical result of this change, from the aarch64/elflint point of view is that the _GLOABL_OFFSET_TABLE_ pointer no longer points to the start of the .got section.  Instead it points to the start of the writable entries *inside* the .got section.  So elflint needs to be updated to take this into account.  _GLOBAL_OFFSET_TABLE_ must still point to somewhere inside the .got section, just not necessarily the start.

Cheers
  Nick

I'll create a patch for elfutils backends/aarch64_symbol.c