Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1422461 - ppc64 .gnu.attributes section all zeros with SHF_EXCLUDE flag
Summary: ppc64 .gnu.attributes section all zeros with SHF_EXCLUDE flag
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1423518 (view as bug list)
Depends On:
Blocks: F26FTBFS
TreeView+ depends on / blocked
 
Reported: 2017-02-15 11:45 UTC by Mark Wielaard
Modified: 2017-02-17 21:20 UTC (History)
4 users (show)

Fixed In Version: 2.27-19.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-17 21:20:25 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
gcc -g -O2 -c t.c (deleted)
2017-02-16 17:44 UTC, Mark Wielaard
no flags Details

Description Mark Wielaard 2017-02-15 11:45:24 UTC
Building elfutils triggers a bad "self test" running eu-elflint against binutils-2.27-16.fc26.ppc64le. It is caused by one of the binaries having a .gnu.attributes section with the SHF_EXCLUDE flag set and containing only zeros.

$ eu-readelf -S src/readelf | grep .gnu.attributes
[34] .gnu.attributes      GNU_ATTRIBUTES 0000000000000000 000f292a 00000010  0 E      0   0  1

$ eu-readelf -x .gnu.attributes src/readelf

Hex dump of section [34] '.gnu.attributes', 16 bytes at offset 0xf292a:
  0x00000000 00000000 00000000 00000000 00000000 ................

This does not happen if I use binutils ld from upstream git trunk. Then the .gnu.attributes section doesn't have the SHF_EXCLUDE flag in the ET_EXEC file and the section content looks like normal.

I have some trouble building older versions of binutils with current gcc, so I haven't been able to pin-point when this issue was introduced and/or fixed.

koji build log for elfutils on rawhide:
https://kojipkgs.fedoraproject.org//work/tasks/457/17720457/build.log

Note that independently of this bug, there is actually a bug in elfutils. elfutils doesn't expect .gnu.attributes sections for EM_PPC64, only for EM_PPC. I'll fix that, but it won't be able to make sense of the zero-filled section.

Comment 1 Mark Wielaard 2017-02-15 14:08:43 UTC
(In reply to Mark Wielaard from comment #0)
> Note that independently of this bug, there is actually a bug in elfutils.
> elfutils doesn't expect .gnu.attributes sections for EM_PPC64, only for
> EM_PPC. I'll fix that, but it won't be able to make sense of the zero-filled
> section.

I fixed that and added the patches to the fedora elfutils rawhide package:

0.168-5 - Add patches for new gcc warnings and new binutils ppc64 attributes.
  - elfutils-0.168-libasm-truncation.patch
  - elfutils-0.168-ppc64-attrs.patch

It still fails on ppc64/ppc64le because of the zeroed out .gnu.attributes section with SHF_EXCLUDE flag.

Comment 2 Nick Clifton 2017-02-16 10:40:31 UTC
Hi Mark,

> Building elfutils triggers a bad "self test" running eu-elflint against
> binutils-2.27-16.fc26.ppc64le. It is caused by one of the binaries having a
> .gnu.attributes section with the SHF_EXCLUDE flag set and containing only
> zeros.

Would it be possible for you to isolate the compilation that is producing the broken binary, and post it here ?

I think that this bug *might* be fixed by:

  https://www.sourceware.org/ml/binutils/2016-09/msg00167.html

but I would like to be able to check it first.

Cheers
  Nick

Comment 3 Mark Wielaard 2017-02-16 12:02:50 UTC
Simplest reproducer is:

$ cat  t.c
#include <stdio.h>

double d = 1.0;

int
main (int argc, char **argv)
{
  printf ("double: %f\n", d);
}
$ gcc -g -O2 -c t.c
$ gcc -o t t.o
$ eu-readelf -x .gnu.attributes t.o

Hex dump of section [23] '.gnu.attributes', 16 bytes at offset 0xa50:
  0x00000000 410f0000 00676e75 00010700 00000401 A....gnu........
$ eu-readelf -x .gnu.attributes t

Hex dump of section [33] '.gnu.attributes', 16 bytes at offset 0x109e1:
  0x00000000 00000000 00000000 00000000 00000000 ................
$ eu-readelf -S t.o | grep .gnu.attributes 
[23] .gnu.attributes      GNU_ATTRIBUTES 0000000000000000 00000a50 00000010  0        0   0  1
$ eu-readelf -S t | grep .gnu.attributes[33] .gnu.attributes      GNU_ATTRIBUTES 0000000000000000 000109e1 00000010  0 E      0   0  1

(With the fixed eu-readelf version you will also be able to use eu-readelf -A to show the actual gnu attributes. But as you can see the bytes in the EXEC are zeroed and the SHF_EXCLUDE flag on the section, which is the actual bug in this case.)

Comment 4 Nick Clifton 2017-02-16 17:14:47 UTC
Hi Mark,

> $ gcc -o t t.o

Could you upload that t.o file please ?

I am trying to reproduce this problem on a F25 ppc64le box, but the gcc installed on that system does not create a .gnu.attributes section.  (I could not find an F26 ppc64le installation ... :-(

Cheers
  Nick

Comment 5 Mark Wielaard 2017-02-16 17:44:34 UTC
Created attachment 1250930 [details]
gcc -g -O2 -c t.c

Build with:

gcc-7.0.1-0.6.fc26.ppc64le
binutils-2.27-16.fc26.ppc64le

Comment 7 Mark Wielaard 2017-02-17 14:01:54 UTC
*** Bug 1423518 has been marked as a duplicate of this bug. ***

Comment 9 Nick Clifton 2017-02-17 14:39:15 UTC
Hi Mark,

  Thanks - with that t.o file I can now reproduce the problem, and I believe
  that I have found a solution.  The problem was that the rawhide gcc is
  newer than the rawhide binutils, and in particular it is generating an
  attribute value for the Floating Point Size which the binutils were not
  expecting.

  Fortunately it turns out that Alan Modra's patch mentioned in comment #2
  fixes this problem.  So please could you try out binutils-2.27-19.fc26
  which contains this patch.

Cheers
  Nick

Comment 10 Mark Wielaard 2017-02-17 21:20:25 UTC
I rebuild elfutils against 2.27-19.fc26 and on both ppc64 and ppc64le it now has zero FAIL. Thanks.


Note You need to log in before you can comment on or make changes to this bug.