Bug 18741

Summary: Corrupted .ARM.attributes section with -meabi=gnu option
Product: binutils Reporter: markus.eisenmann
Component: binutilsAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: markus.eisenmann, nickc
Priority: P2    
Version: 2.25   
Target Milestone: ---   
Host: Target: arm-eabi
Build: Last reconfirmed:
Attachments: example object file

Description markus.eisenmann 2015-07-30 14:07:20 UTC
I've created an GCC-toolchain with target=arm-eabi (using GCC 4.9.3, binutils 2.25) and use it with the option -mabi=apcs-gnu.

It still works, but I've received the readelf error-message "Unused bytes at end of section" if I check the generated object-files.
The .ARM.attributes section seems to be corrupted and has the (hex) content:
41 0f 00 00 00 61 65 61 62 69 00 01 05 00 00 00 (section-size = 0x10).
After some tests - producing assembler-code and calling AS - I've detected the AS-option -meabi=gnu as origin cause of this issue. In this case an corrupted/incomplete .ARM.attributes-content (as above) will be generated in the elf-output; with -meabi=4 (or 5) readeld shows the ARM-attributes w/o any error-message.

Best regards from Salzburg,
Markus
Comment 1 markus.eisenmann 2015-07-31 08:24:43 UTC
Debugging of BDF- and GAS-sources has shown following behavior:

With calling AS-option meabi=gnu there are now (ARM-) attributes;
I.e. size = 0 in function vendor_obj_attr_size() [bfd/elf-attrs.c] before return,
but in case of vendor == OBJ_ATTR_PROC a value of '10 + strlen(vendor_name)'
is always added.

Afterwards in GAS - function create_obj_attrs_section() [gas/write.c] - size is
therefore greater 0 and the section ".ARM.attributes" will be emitted.
In this case without any attributes (after the vendor-name) and results in corrupted content.

Sorry, I'm not familiar with the BDF-internals and requirements, but IMHO:
 a) adding of '10 + strlen(vendor_name)' in vendor_obj_attr_size() causes this issue,
 b) or in create_obj_attrs_section() (of GAS) should be aborted if 'size - strlen(name) - 10' is 0 (like indicator, that there are no applied attributes) as counterpart.

May be this findings above can help to find a suitable fix;
Anyway, I'm looking forward for a answer of an experienced binutils-developer ...

BR,
Markus
Comment 2 markus.eisenmann 2015-08-03 06:36:52 UTC
Further findings (IMHO - what I think):

A) bdf/elf-attrs.c: function vendor_set_obj_attr_contents():

Fix of file-attributes length; previous tag-byte not counted.

--- bdf/elf-attrs.c
+++ bdf/elf-attrs.c
@@ -183,7 +183,7 @@
   memcpy (p, vendor_name, vendor_length);
   p += vendor_length;
   *(p++) = Tag_File;
-  bfd_put_32 (abfd, size - 4 - vendor_length, p);
+  bfd_put_32 (abfd, size - 5 - vendor_length, p);
   p += 4;
 
   attr = elf_known_obj_attributes (abfd)[vendor];


B) bdf/elf-attrs.c: function vendor_obj_attr_size():

Even in case of vendor==OBJ_ATTR_PROC do not adjust size if there are no attributes.

--- bdf/elf-attrs.c
+++ bdf/elf-attrs.c
@@ -104,7 +104,7 @@
     size += obj_attr_size (list->tag, &list->attr);
 
   /* <size> <vendor_name> NUL 0x1 <size> */
-  return ((size || vendor == OBJ_ATTR_PROC)
+  return (size
 	  ? size + 10 + strlen (vendor_name)
 	  : 0);
 }

In case of B), I'm not sure whether this is valid; Or readelf should be fixed to recognize an empty attribute-list after the vendor-name?

Best regards from Salzburg,
Markus

P.S.: May a binutils-maintainer can review this issue and confirm, whether this is really an bug (or not)?
Comment 3 markus.eisenmann 2015-08-03 10:55:22 UTC
Sorry!

Forget my last comment about the sub-section size;
as in http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044e/IHI0044E_aaelf.pdf described, the sub-section size includes the size-field and the previous tag-byte.

But the origin described issue (readelf-warning about unused bytes) is still valid.

Question: Is a nearby empty ARM-Attributes section for the the "Old" EABI needed?
Comment 4 Nick Clifton 2015-08-12 11:38:01 UTC
Hi Markus,

  I cannot reproduce this problem. :-(

  Please could you test to see if you can make the problem happen using the latest mainline development sources ?  If you can, please could you upload the test case so that I can try it for myself.

Cheers
  Nick
Comment 5 markus.eisenmann 2015-08-12 13:20:50 UTC
Hi Nick!

I have generated a GCC-Cross-Compiler for arm-eabi, and (have to) use it with the option ARM-option "-mabi=apcs-gnu" (I.e. OABI);
using:
 GCC 4.9.2
 binutils 2.25 (but this issue still occurs with 2.25.1)
 newlib 2.1.0

In this case the GNU-AS (which is used by the compiler) generates an .ARM.attributes segment with vendor "aeabi" but no sub-fields (attributes).
Therefore readelf shows an .ARM.attributes-segment with a size of 16 Byte.

But readelf (for this ELF-output) gives me the warning "Unused bytes at end of section", since there's an empty sub-field (less than 6 byte).

At least, it's more a "problem" of readelf and it's handling of (assumed) corrupted attribute-entries. On the other hand, it is necessary to emit an .ARM.attributes section for OABI-compiles?

----------------------------------------------------------------------
Sorry, currently I'm not find a public arm-eabi toolchain which uses binutils 2.25 - but there's the "way" ... :

Compile an empty source-file (I.e. empty.c) with:
>arm-eabi-gcc -c -mabi=apcs-gnu empty.c

>arm-eabi-readelf -a empty.o
will show the .ARM.attributes section (type ARM_ATTRIBUTES) with a size of 16 byte.

If readelf is of version 2.24 it will show the ARM_ATTRIBUTES as:
    No version information found in this file.
    Attribute Section: aeabi
    File Attributes
and nothing more, a version 2.25 readelf instead shows me:
    No version information found in this file.
    Attribute Section: aeabi
    readelf: Error: Unused bytes at end of section

----------------------------------------------------------------------

Background information:
I have to build a newer toolchain for arm-eabi; (very) earlier version of GCC/binutils (2.19) do not emit an ARM-attributes section in case of OABI.

After building this newer version, I've seen this readelf-warning and thought,
that's really corrupted section; Now I think, it's more a "overshooting" miss-interpretation by readelf (with Bug 17531). 

Because, I need a toolchain which behave more compatible to earlier GCC/binutils combinations, I'm using following private work-around:

--- binutils-2.25/gas/write.c	Tue Nov 04 10:54:41 2014
+++ binutils-2.25/gas/write.c	(working copy)
@@ -1772,6 +1772,9 @@
       name = get_elf_backend_data (stdoutput)->obj_attrs_section;
       if (!name)
 	name = ".gnu.attributes";
+      // ME: Drop (nearby) empty '.ARM.attributes' section!
+      else if ((size <= 16) && !stricmp(name, ".ARM.attributes")) return;
+
       s = subseg_new (name, 0);
       elf_section_type (s)
 	= get_elf_backend_data (stdoutput)->obj_attrs_section_type;
---
to do not emit this section in this (special) case; for EABI>=5 size will be greater than 16 Byte (because there are ARM-attributes).

I'm not sure, whether an ARM-attributes section is required for OABI-build (I.e. EABI=0, -mabi=apcs-gnu) ?!

Best regards,
Markus

P.S.: Sorry for noise - if it's not a real issue and more a minor "blemish".
Comment 6 Nick Clifton 2015-08-14 08:19:44 UTC
Created attachment 8519 [details]
example object file
Comment 7 Nick Clifton 2015-08-14 08:22:33 UTC
Hi Markus,

> Compile an empty source-file (I.e. empty.c) with:
>arm-eabi-gcc -c -mabi=apcs-gnu empty.c
>arm-eabi-readelf -a empty.o
> will show the .ARM.attributes section (type ARM_ATTRIBUTES) with a 
> size of 16 byte.

Well I tried this using the FSF GCC and binutils mainline sources and the problem did not occur - ie the object file contains the correct attributes and readelf does not complain.  I have uploaded a copy of the object file for you to examine if you wish.

My guess is that this is a bug which has already been fixed, some time after 2.25 was released.  Since it is a minor problem I am not going to search for the patch and backport it to 2.25, unless you can convince me otherwise.

Cheers
  Nick
Comment 8 markus.eisenmann 2015-08-14 11:30:18 UTC
Hi Nick!

The readelf-output (Version 2.25) of your sample is (showing ARM-Attributes):
  Attribute Section: aeabi
  File Attributes
    Tag_ARM_ISA_use: Yes
    Tag_THUMB_ISA_use: Thumb-1

It contains sub-fields; I.e., it seems, that with binutils mainline these two default-attributes are emitted (instead of nothing as before for OABI).

> My guess is that this is a bug which has already been fixed, some time after
> 2.25 was released.  Since it is a minor problem I am not going to search for
> the patch and backport it to 2.25, unless you can convince me otherwise.

No, thanks - it is fixed for future releases. And as I have described in comment #5, I have a (private) work-around or will discard the .ARM.attributes-section at link-time (with a linker-script) to make our post-processing ELF-utilities happy!

BR,
Markus
Comment 9 Alan Modra 2022-08-03 11:08:28 UTC
.