[PATCH v3 2/2] aarch64: Add memory tagging support for setjmp/longjmp routines

[Claudiu Zissulescu]

>>
>> This patch relies on the USE_MTAG macro, which must be defined through
>> the --enable-memory-tagging option.
> 
> This flag also enables heap tagging in malloc. We probably shouldn't
> enable both with the same flag as the use cases could be quite
> different.

I can add a different one. However, the above flag needs to be reworked 
as the name and its documentation is too wide.

>> +      LIBC_TRY_CC_OPTION([$CFLAGS $CPPFLAGS -Werror -fsanitize=memtag-stack -march=armv8.5-a+memtag],
> 
> This check fails on GCC 15.2.1. Will the support be added in GCC 16?
> 
Yes.


>> +ifeq (yes,$(have-memtag-sanitizer))
>> +tests += tst-mte-jmp \
>> +	tst-mte-stack
> 
> Nit: this usually should be written as
> 
>    +tests += \
>    +  tst-mte-jmp \
>    +  tst-mte-stack \
>    +  # tests
> 
Noted.

>> +CFLAGS-tst-mte-jmp.c += -fsanitize=memtag-stack -march=armv8.5-a+memtag
>> +LDFLAGS-tst-mte-jmp += -Wl,-z,memtag-stack -Wl,-z,memtag-mode=sync
>> +CFLAGS-tst-mte-stack.c += -fsanitize=memtag-stack -march=armv8.5-a+memtag -w
> 
> Probably don't use -w? What are the warnings that need to be suppressed?

gcc16 complains about the sink value not being use. I'll find a better 
way to deal with that.

> 
>> +LDFLAGS-tst-mte-stack += -Wl,-z,memtag-stack -Wl,-z,memtag-mode=sync
> 
> What about testing sync mode?

We can have the same tests executed with async mode too. However, this 
patch doesn't test the hardware capabilities, but the feature of 
handling mte enabled stacks.

> +
>> +#undef count
>> +#undef tmp
>> +#endif
>> +
> 
> Is this guaranteed to work with stack tagging implemented by other
> compilers? Is there a spec for this ABI?

The above is design to handle the output of the only compiler which can 
generate MTE and compile glibc which I know. Please, let me know if 
there are any other compilers that do that, as well as their 
documentation covering their MTE implementation.


>> +static int
>> +do_test (void)
>> +{
>> +  volatile unsigned char array[15];
>> +  volatile unsigned char *ptr = &array[0];
> 
> Should there be a check for tag being set in this pointer to the memory
> allocated on stack?

The tag is set by the gcc compiler via -fsanitize=memtag-stack. The 
compiler has it's own set of tests that is checking if it does a good 
job setting the tags. Checking if the compiler does its job here seems 
to me a bit over-engineering.

> 
> Should we also check alloca() result?

I can add a test for alloca. The master plan is the same.

> 
>> +  unsigned long hwcap2;
>> +
>> +  hwcap2 = getauxval (AT_HWCAP2);
>> +  if ((hwcap2 & HWCAP2_MTE) == 0)
>> +    return EXIT_UNSUPPORTED;
> 
> Nit: it's usually helpful to print a message to tell why the test is
> unsupported.

I can add a message.

Best wishes,
Claudiu