ARM attribute merging oddity

[Andrew Stubbs]

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