[PATCH v0 11/15] bfd: merge duplicated subsections into one after parsing
Matthieu Longo
matthieu.longo@arm.com
Thu Mar 20 15:23:34 GMT 2025
On 2025-03-11 08:15, Jan Beulich wrote:
> On 10.03.2025 18:51, Matthieu Longo wrote:
>> Several subsections with the same name can be present inside an object
>> file depending on how it was generated. Gas won't generate such an
>> object as it is able to detect scattered declaration of a subsection,
>> and merge its content before the serialization. However, others
>> assemblers than Gas might keep the subsections separated, and opted for
>> delegating the merge to the linker.
>> Additionally, a subsection can be populated before the parsing the
>> attributes section if some GNU properties are convertible to build
>> attributes.
>> In order to make the merge logic between object files simpler, the
>> deserializer is able to handle to perform an union of the duplicated
>> subsections inside an object.
>> Since the same deserializaton code is used by objcopy, it means that
>> objcopy won't simply copy the data to the output object, but will also
>> merge duplicated subsections together, so the readelf output between
>> the two objects will be different. This might be seen as a bug but,
>> given that gas will never generate such an object, I would argue that
>> it is an acceptable design choice.
>
> I tend to disagree: objcopy isn't linking. ld -r may do such combining,
> but imo objcopy shouldn't.
>
> Jan
The way I implemented the translation of GNU properties to OAv2 was a
quick hack. I thought the side effect was acceptable but you are very
right on the principle that objcopy's role is copy the data in the
sections to the output object without any transformation of those data.
I changed where this translation happened, and automatically it removed
the deduplication of subsections and attributes, and sorting outside of
objcopy path.
Fixed in the next revision.
More information about the Binutils
mailing list