[PATCH v10 15/28] OAv2 merge: find first input containing an object attributes section

[Jan Beulich]

On 18.12.2025 16:40, Matthieu Longo wrote:
> On 10/12/2025 11:14, Jan Beulich wrote:
>> On 20.11.2025 18:59, Matthieu Longo wrote:
>>> @@ -729,6 +749,41 @@ typedef struct
>>>     asection *sec;
>>>   } bfd_search_result_t;
>>>   
>>> +/* Checks whether a BFD contains object attributes, and if so search for the
>>> +   relevant section storing them.  The name and type of the section have to
>>> +   match with what the backend expects, i.e. elf_backend_obj_attrs_section and
>>> +   elf_backend_obj_attrs_section_type, otherwise the object attributes section
>>> +   won't be recognized as such, and will be skipped.
>>> +   Return True if an object attribute section is found, False otherwise.  */
>>> +static bool
>>> +bfd_has_object_attributes (const struct bfd_link_info *info,
>>> +			   bfd *abfd,
>>> +			   bfd_search_result_t *res)
>>> +{
>>> +  /* The file may contain object attributes.  Save this candidate.  */
>>> +  res->pbfd = abfd;
>>> +
>>> +  if (elf_obj_attr_subsections (abfd).size == 0)
>>> +    return false;
>>> +
>>> +  res->has_object_attributes = true;
>>
>> For my own understanding / education: Is there being no attributes section
>> identical to there being a zero-size one?
> 
> At this stage, yes, if no attribute section is present, this list is empty.
> However, after translation of GNU properties, this is not true anymore.

Hmm, okay, but this doesn't answer my question.

>>> @@ -737,9 +792,18 @@ typedef struct
>>>   static bfd_search_result_t
>>>   bfd_linear_find_first_with_obj_attrs (const struct bfd_link_info *info)
>>>   {
>>> -  (void) info;
>>> -  /* TO IMPLEMENT */
>>> -  bfd_search_result_t res = {NULL, false, NULL};
>>> +  bfd_search_result_t res = {
>>> +    .pbfd = NULL,
>>> +    .has_object_attributes = false,
>>> +    .sec = NULL,
>>> +  };
>>
>> If (later) a field was added to the struct, would you really expect the
>> initializer here to be updated? Else why the spelling out of the zero-
>> initialization?
> 
> Ideally yes, but in my understanding, the compiler unfortunately won't complain about the missing one.

It would be wrong for it to complain, yet again that's not really addressing
my question. Let me put it in different words then: Why the three field
initializers when one would do? (Sadly none at all is not an options with
plain C99, iirc.)

>>> +  for (bfd *abfd = info->input_bfds; abfd != NULL; abfd = abfd->link.next)
>>> +    {
>>> +      if (elf_may_contain_obj_attrs (info, abfd)
>>> +	  && bfd_has_object_attributes (info, abfd, &res))
>>> +	break;
>>
>> I'm curious: Why is one of the functions prefixed elf_ and the other bfd_,
>> when really they are about the same underlying aspect (aiui), and the
>> latter one is also very much ELF-specific?
> 
> The function bfd_has_object_attributes() is not prefixed, it is part of the name for "Does the given bfd has object attributes ?".

Hmm, I can kind of understand this, but view it as unfortunate. The bfd_ part
of the name space would better serve a single purpose.

> Same comment for elf_may_contain_obj_attrs().

This, however, I don't understand: There's no "elf" passed into the function,
and there's also no entity in libbfd which would be named "elf". You're still
querying a bfd, so by your reasoning for the other function if should also
start with bfd_ (and then maybe bfd_elf_, further increasing the name space
issues).

Jan