ARM attribute merging oddity
Andrew Stubbs
ams@codesourcery.com
Fri Mar 20 09:38:00 GMT 2009
On 19/03/09 20:12, Daniel Jacobowitz wrote:
> From the top of elf32_arm_merge_eabi_attributes:
>
> if (!elf_known_obj_attributes_proc (obfd)[0].i)
> {
> /* This is the first object. Copy the attributes. */
> _bfd_elf_copy_obj_attributes (ibfd, obfd);
>
> /* Use the Tag_null value to indicate the attributes have been
> initialized. */
> elf_known_obj_attributes_proc (obfd)[0].i = 1;
>
> return TRUE;
> }
>
> This means that we don't warn about unknown attributes if they're in
> the very first file, and if every file has the unknown attribute with
> the same value - or does not have it at all - then the output file
> will include it. But if the first file doesn't have it and a later
> file does, it'll be warned about and dropped.
>
> Do we need to run through the full merging process for the first
> file too?
I think any process that messes with attributes for files that are not
being changed is wrong (i.e. one input -> one output).
IIRC, most of the tests check whether both inputs are good, and will
give an error message for either one of them. This means that as
multiple files are merged, the "out" file's attributes - initially a
copy of the first "in" file, get continually rechecked, but it's the
only way to check the first file in the current setup.
If a particular check is missing this, then probably that's a bug.
Andrew
More information about the Binutils
mailing list