On 26/02/2026 16:19, Richard Earnshaw (foss) wrote:
> On 05/02/2026 15:30, Matthieu Longo wrote:
>> On 05/02/2026 15:02, Richard Earnshaw (foss) wrote:
>>> On 30/01/2026 16:55, Matthieu Longo wrote:
>>>> When branch protections are enabled (see -mbranch-protection), GCC tags
>>>> the output object file with metadata describing which security features
>>>> are used, allowing the GNU linker to detect incompatibilities between
>>>> objects in the same link unit.
>>>>
>>>> Originally, this metadata was conveyed via GNU properties. GCC emitted a
>>>> .note.gnu.property section containing a GNU_PROPERTY_AARCH64_FEATURE_1_AND
>>>> entry.
>>>> Build Attributes v2 (OAv2) aim at replacing GNU properties, provinding
>>>> a more flexible way to express complex metadata and making easier for
>>>> tools like linkers to parse them.
>>>>
>>>> Since the runtime linker only understands GNU properties, the GNU static
>>>> linker translates OAv2 attributes into GNU properties. As a result,
>>>> emitting both GNU properties and OAv2 in the same object file is redundant.
>>>> When GCC detects OAv2 support in GNU binutils, it therefore emits only
>>>> OAv2 directives.
>>>>
>>>> Support for OAv2 was added in [1], along with new tests covering both
>>>> the emission/omission of GNU properties/OAv2 directives. However, an older
>>>> BTI test that checked for the presence of a GNU properties section was
>>>> left unchanged. This test now fails when GNU binutils support OAv2, as no
>>>> GNU properties are emitted.
>>>>
>>>> This patch removes the expectations of the presence of GNU properties from
>>>> that BTI test.
>>>>
>>>> [1]: 98f5547dce2503d9d0f0cd454184d6870a315538
>>>>
>>>> gcc/testsuite/ChangeLog:
>>>>
>>>> * gcc.target/aarch64/bti-1.c: Update.
>>>> ---
>>>> gcc/testsuite/gcc.target/aarch64/bti-1.c | 2 --
>>>> 1 file changed, 2 deletions(-)
>>>>
>>>> diff --git a/gcc/testsuite/gcc.target/aarch64/bti-1.c
>>>> b/gcc/testsuite/gcc.target/aarch64/bti-1.c
>>>> index 53dc2d3cd8b..174b62eb05b 100644
>>>> --- a/gcc/testsuite/gcc.target/aarch64/bti-1.c
>>>> +++ b/gcc/testsuite/gcc.target/aarch64/bti-1.c
>>>> @@ -61,5 +61,3 @@ lab2:
>>>> }
>>>> /* { dg-final { scan-assembler-times "hint\t34 // bti c" 1 } } */
>>>> /* { dg-final { scan-assembler-times "hint\t36 // bti j" 12 } } */
>>>> -/* { dg-final { scan-assembler "\.section\t\.note\.gnu\.property" {
>>>> target *-*-linux* } } } */
>>>> -/* { dg-final { scan-assembler "\.word\t0x7\t\/\/
>>>> GNU_PROPERTY_AARCH64_FEATURE_1_AND \\(BTI, PAC, GCS\\)" { target
>>>> *-*-linux* } } } */
>>>
>>> Wouldn't it be better to qualify the test for when the assembler lacks
>>> this, something like
>>> ... { target { *-*-linux* && aarch64_gas_has_build_attributes } } } } */
>>>
>>
>> Not really, because this test is redundant now with the following tests:
>> gcc/testsuite/gcc.target/aarch64/build-attributes/no-build-attribute-bti.c
>> gcc/testsuite/gcc.target/aarch64/build-attributes/no-build-attribute-gcs.c
>> gcc/testsuite/gcc.target/aarch64/build-attributes/no-build-attribute-pac.c
>>
>> gcc/testsuite/gcc.target/aarch64/build-attributes/no-build-attribute-standard.c
>>
>> This part in the commit description was supposed to clarify this point.
>> > Support for OAv2 was added in [1], along with new tests covering both
>> > the emission/omission of GNU properties/OAv2 directives.
>>
>> To keep things simple and coherent (otherwise, why don't GCS tests also test
>> for GCS tag ? or PAC tests PAC tag ?), it seems to me that it is better to
>> remove the check.
>>
>>>> \ No newline at end of file
>>>
>>> And please fix this as well.
>>
>> My editor automatically inserts a new line at the end of the file.
>> This behavior seems correct to me. Isn't it correct ?
>>
>
> Well it seems to have faile then in this case, since that marker indicates
> one is missing...
>
Actually, no. I misunderstood how diff files represent this information. In
essence the note is bound to the line before, which in this case is a line
deletion of a line that lacked a trailing newline character. So this deletes a
line with no trailing newline, leaving the last line with the correct \n char.
My apologies.
R.
>>>
>>> R.
>>
>> Matthieu
>>
>
> OK if you fix up that nit.
>
> R.
