Summary: | Corrupted .ARM.attributes section with -meabi=gnu option | ||
---|---|---|---|
Product: | binutils | Reporter: | markus.eisenmann |
Component: | binutils | Assignee: | 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
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 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)? 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? 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 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". Created attachment 8519 [details]
example object file
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
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 . |