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

[Matthieu Longo]

On 18/12/2025 16:29, Jan Beulich wrote:
> 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.
> 

A zero-sized attribute section, or a no section result in the same behavior.
The subsection list will be empty.

>>>> @@ -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.)
> 

What do you mean "one would do" ?
Something like "bfd_search_result_t res = {0};" ?

>>>> +  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.
> 

What about renaming the function to input_bfd_has_object_attributes ?

>> 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

The function was removed in the next revision so it should not be an issue anymore.

Matthieu