Home Original page

[PATCH v9 16/19] gnu directives: add support for gnu_attribute and gnu_subsection in OAv2 context

Matthieu Longo matthieu.longo@arm.com
Fri Nov 7 16:02:48 GMT 2025 
On 07/11/2025 09:00, Jan Beulich wrote:
> On 06.11.2025 17:39, Matthieu Longo wrote:
>> On 31/10/2025 12:48, Jan Beulich wrote:
>>> On 01.09.2025 18:56, Matthieu Longo wrote:
>>>> --- a/bfd/elf-attrs.c
>>>> +++ b/bfd/elf-attrs.c
>>>> @@ -2667,10 +2667,11 @@ oav2_parse_subsection (bfd *abfd,
>>>>        }
>>>>    
>>>>      const char *vendor_name = get_elf_backend_data (abfd)->obj_attrs_vendor;
>>>> -  obj_attr_subsection_scope_v2 scope
>>>> -    = (strncmp (subsection_name, vendor_name, strlen (vendor_name)) == 0
>>>> -      ? OA_SUBSEC_PUBLIC
>>>> -      : OA_SUBSEC_PRIVATE);
>>>> +  obj_attr_subsection_scope_v2 scope = OA_SUBSEC_PRIVATE;
>>>> +  if (strncmp (subsection_name, vendor_name, strlen (vendor_name)) == 0
>>>> +      || (strncmp (subsection_name, "gnu", 3) == 0
>>>> +	  && !gnu_testing_namespace (subsection_name)))
>>>> +    scope = OA_SUBSEC_PUBLIC;
>>>>    
>>>>      *subsec = _bfd_elf_obj_attr_subsection_v2_init
>>>>        (subsection_name, scope, comprehension_raw, value_encoding);
>>>> --- a/binutils/readelf.c
>>>> +++ b/binutils/readelf.c
>>>> @@ -20014,7 +20014,9 @@ elf_parse_attrs_subsection_v2 (unsigned char *cursor,
>>>>          const char *subsec_name = (const char *) cursor;
>>>>          printf (_(" - Name:	  %s\n"), subsec_name);
>>>>          bool public_subsection
>>>> -	= strncmp (subsec_name, public_name, strlen (public_name)) == 0;
>>>> +	= (strncmp (subsec_name, public_name, strlen (public_name)) == 0
>>>> +	   || (strncmp (subsec_name, "gnu", 3) == 0
>>>> +	       && strncmp (subsec_name + 3, "-testing", 8) != 0));
>>>>          cursor += subsection_name_len;
>>>>          op.read += subsection_name_len;
>>>>    
>>>> --- a/gas/config/obj-elf-attr.c
>>>> +++ b/gas/config/obj-elf-attr.c
>>>> @@ -1078,10 +1078,11 @@ obj_attr_v2_subsection_record (const char *name,
>>>>    
>>>>          const char *vendor_name
>>>>    	= get_elf_backend_data (stdoutput)->obj_attrs_vendor;
>>>> -      obj_attr_subsection_scope_v2 scope
>>>> -	= (strncmp (name, vendor_name, strlen (vendor_name)) == 0
>>>> -	   ? OA_SUBSEC_PUBLIC
>>>> -	   : OA_SUBSEC_PRIVATE);
>>>> +      obj_attr_subsection_scope_v2 scope = OA_SUBSEC_PRIVATE;
>>>> +      if (strncmp (name, vendor_name, strlen (vendor_name)) == 0
>>>> +	  || (strncmp (name, "gnu", 3) == 0
>>>> +	      && strncmp (name + 3, "-testing", 8) != 0))
>>>> +	scope = OA_SUBSEC_PUBLIC;
>>>
>>> Three times the effectively same check - shouldn't there be a helper centralizing
>>> this?
>>>
>>
>> See my reply in patch 9/19.
>>
>> I moved the code to this helper:
>>
>> /* Identify the scope of a subsection from its name.  */
>> obj_attr_subsection_scope_v2
>> bfd_elf_obj_attr_subsection_v2_scope (bfd *abfd, const char *subsec_name)
>> {
>>      const char *vendor_name = get_elf_backend_data (abfd)->obj_attrs_vendor;
>>      obj_attr_subsection_scope_v2 scope = OA_SUBSEC_PRIVATE;
>>      size_t vendor_name_len = strlen (vendor_name);
>>      if ((strncmp (subsec_name, vendor_name, vendor_name_len) == 0
>>           && subsec_name[vendor_name_len] == '_')
>>          || (strncmp (subsec_name, "gnu_", 4) == 0
>> 	  && !gnu_testing_namespace (subsec_name)))
>>        scope = OA_SUBSEC_PUBLIC;
>>      return scope;
>> }
> 
> Yet that still doesn't cover readelf, aiui. Please have cross-ref comments
> at both sites then, to make clear that both need keeping in sync.
> 

Yes, it does not cover readelf.
I added a cross reference in the next revision.

>>>> +/* Parse a .gnu_subsection directive.  */
>>>> +
>>>> +static void
>>>> +obj_elf_gnu_subsection (int ignored ATTRIBUTE_UNUSED)
>>>> +{
>>>> +  obj_attr_version_t version = elf_obj_attr_version (stdoutput);
>>>> +  if (! attr_fmt_has_subsections (version))
>>>> +    {
>>>> +      as_bad (_(".gnu_subsection is only available with object attributes v2,"
>>>> +		" and the current target only supports object attributes v1"));
>>>
>>> This message, first of all, is liable to go stale the moment some target supports
>>> both v1 and v2.
>>
>> The version specified in the backend corresponds to the only-supported
>> output format for a given backend. If a backend wants to migrate, and
>> sets this to OAv2, it means that no object with OAv1 can be generated
>> with this version of binutils. However, OAv1 objects would be accepted
>> at link time, but the resulting build artifact will only contain OAv2. I
>> said "would" because this requires a translation layer implemented by
>> the backend, and there is no such example today.
>>
>> How is this relevant to parsing ?
>> For parsing, nowhere the spec mentioned a way to indicate what version
>> of OAv1 or OAv2 is used in an assembly file. If you look at the cover
>> letter, I proposed a flag --obj-attr=[OAv1|OAv2] for such a use case,
>> but I would say that adding such an option is out of scope for this
>> patch series. This option would allow a period where files can be
>> migrated one by one, instead of migrating everything at the same time.
>> If the approach of a command line option were adopted, the check should
>> use a value other than elf_obj_attr_version (stdoutput) (i.e. the
>> preferred output format), which would store the command line option value.
>>
>> Given that this option is hypothetical until someone decides to go
>> through a migration, I would recommend not to pay too much attention to
>> this check. What is you opinion about this given the previous explanation ?
>>
>>   > I also think (see other respective remarks elsewhere) that the>
>> diagnostic is too long. AT the very least the second "object attributes"
>> looks
>>> redundant, for example.
>>>
>>
>> Yes, I agree. What about this simpler sentence, but a bit vague in my
>> opinion.
>>
>> ".gnu_subsection is only available with object attributes v2"
> 
> I'd be fine with this, as it also addresses my other comment above.
> 

Fixed.

>>>> @@ -5745,6 +5746,10 @@ partial programs.  You may need the HPPA-only @code{.EXPORT} directive as well.
>>>>    @end ifset
>>>>    
>>>>    @ifset ELF
>>>> +@node Gnu_subsection
>>>> +@section @code{.gnu_subsection @var{name}, @var{comprehension}, @var{encoding}}
>>>> +Record a @sc{gnu} object attribute subsection for this file.  @xref{Object Attributes}
>>>
>>> Here you document the new directive, whereas ...
>>>
>>>> @@ -7954,32 +7959,62 @@ Many architectures support incompatible variations.  For instance, floating
>>>>    point arguments might be passed in floating point registers if the object file
>>>>    requires hardware floating point support---or floating point arguments might be
>>>>    passed in integer registers if the object file supports processors with no
>>>> -hardware floating point unit.  Or, if two objects are built for different
>>>> -generations of the same architecture, the combination may require the
>>>> -newer generation at run-time.
>>>> -
>>>> -This information is useful during and after linking.  At link time,
>>>> -@command{@value{LD}} can warn about incompatible object files.  After link
>>>> -time, tools like @command{gdb} can use it to process the linked file
>>>> -correctly.
>>>> +hardware floating point unit.  Another example might be when two object files
>>>> +make use of different architectural extensions: the final image will require
>>>> +both features to be supported at runtime; or if the features are mutually
>>>> +exclusive, the linker can issue a diagnostic.
>>>>    
>>>> -Compatibility information is recorded as a series of object attributes.  Each
>>>> -attribute has a @dfn{vendor}, @dfn{tag}, and @dfn{value}.  The vendor is a
>>>> -string, and indicates who sets the meaning of the tag.  The tag is an integer,
>>>> -and indicates what property the attribute describes.  The value may be a string
>>>> -or an integer, and indicates how the property affects this object.  Missing
>>>> -attributes are the same as attributes with a zero value or empty string value.
>>>> +@command{@value{AS}} currently supports two versions of object attributes:
>>>> +@itemize @bullet{}
>>>> +@item
>>>> +Object Attributes version 1 (OAv1) used by: ARC, ARM, C-SKY, MIPS, MSP430, M68K,
>>>> +PowerPC, RISC-V, SPARC, s390, and TIC6X.
>>>> +@item
>>>> +Object Attributes version 2 (OAv2) used by: AArch64.
>>>> +@end itemize
>>>>    
>>>> -Object attributes were developed as part of the ABI for the ARM Architecture.
>>>> -The file format is documented in @cite{ELF for the ARM Architecture}.
>>>> +Object attributes are only supported when generating ELF format.
>>>>    
>>>>    @menu
>>>> +* Object Attributes v1::                Object Attributes v1
>>>> +* Object Attributes v2::                Object Attributes v2
>>>>    * GNU Object Attributes::               @sc{gnu} Object Attributes
>>>>    * Defining New Object Attributes::      Defining New Object Attributes
>>>>    @end menu
>>>>    
>>>> +@node Object Attributes v1
>>>> +@section Object Attributes v1
>>>> +
>>>> +In Object Attributes v1 (OAv1) Compatibility information is recorded as a series
>>>> +of object attributes.  Each attribute has a @dfn{vendor}, @dfn{tag}, and
>>>> +@dfn{value}.  The @dfn{vendor} is a string, and indicates who sets the meaning
>>>> +of the tag.  The @dfn{tag} is an integer, and indicates what property the
>>>> +attribute describes.  The @dfn{value} may be a string or an integer, and
>>>> +indicates how the property affects this object.  Integer tags generally default
>>>> +to 0, while string tags default to the empty string.  Tags are only recorded in
>>>> +the file if they have a non-default value.
>>>> +
>>>> +OAv1 were developed as part of the ABI for the ARM Architecture.  The file
>>>> +format is documented in @cite{Addenda to, and Errata in, the ABI for the Arm
>>>> +Architecture}.
>>>> +
>>>> +@node Object Attributes v2
>>>> +@section Object Attributes v2
>>>> +
>>>> +Object Attributes v2 (OAv2) share common concepts of @dfn{vendor}, @dfn{tag}
>>>> +and @dfn{value} with OAv1, but also introduce the new ones like @dfn{subsection}
>>>> +and @dfn{scope}.  Attributes with common properties are grouped into subsections.
>>>> +All the attributes in a subsection share the same encoding, comprehension, and
>>>> +scope.  A subsection starting with the vendor name is considered public.  The
>>>> +value of an attribute may be a string or an integer depending on the encoding
>>>> +set on its subsection.
>>>> +
>>>> +OAv2 is only used by AArch64.  Directives are documented in @ref{AArch64
>>>> +Directives}.  The file format is documented in @cite{Build Attributes for the
>>>> +Arm 64-bit Architecture (AArch64)}.
>>>
>>> ... here you refer to something living elsewhere.
>>
>> I am not sure that I understand what your concern is with the current
>> documentation.
>> Do you mean that I should remove the reference "@xref{Object
>> Attributes}" because the link between this directive, and the
>> explanation of what OAv2 are is not clear, or at least not directly
>> related ?
>> Please could you elaborate ?
> 
> "AArch64 Directives" lives in c-aarch64.texi. The patch doesn't alter that file
> at all, hence why I can't help the impression that the @ref here points to the
> wrong place.

@xref{AArch64 Directives} seems to be the right reference, i.e. the 
syntax of those directives. GNU or not GNU, they all follow the syntax 
of AArch64 ones.

> That said, I may be irritated by it being .gnu_subsection that you
> document here, while at the same time inserting a reference to where
> .aeabi_subsection and .aeabi_attribute are documented. Perhaps this reference
> wants adding there already in patch 04?
> 

What about this phrasing ? Does it clarifies the situation from your 
perspective ?

OAv2 is only used by AArch64. OAv2 directives, GNU or non-GNU, have the 
same format as the AArch64 ones documented in @ref{AArch64 Directives}. 
The file format is documented in @cite{Build Attributes for the Arm 
64-bit Architecture (AArch64)}, the original specification document that 
introduced OAv2.

> It's further unclear to me where exactly the @cite points. Looking back through
> the series, a similar @cite is added in patch 04. There it's also unclear what
> it references. You don't expect people to search the internet for something by
> that title, with unpredictable quality of results, do you? Surely there is a
> stable URL you could supply?
> 
> Jan

Regarding this @cite, the specification document is still a pull 
request, and should be merged once this patch series is merged. 
Consequently, I cannot provide you today a stable URL. Also, when this 
PR is merged, Arm does not guarantee the long-term stability of the 
result. Adding such a cross-site link might become a maintenance burden 
in the future.

If you still want a temporary link, here it is: 
https://github.com/smithp35/abi-aa/blob/build-attributes/buildattr64/buildattr64.rst

Please let me know how you want to proceed.

Matthieu
More information about the Binutils mailing list