[PATCH] tests: allow tests to append tunables

[Yury Khrustalev]

Hi Adhemerval,

You are responding to v1 while there is already v2 as per Carlos'
request and as discussed during the weekly call on Monday:

https://inbox.sourceware.org/libc-alpha/20260413142618.405790-1-yury.khrustalev@arm.com/

On Tue, Apr 14, 2026 at 04:25:01PM -0300, Adhemerval Zanella Netto wrote:
> 
> 
> On 24/03/26 11:14, Yury Khrustalev wrote:
> > Many tests use Glibc tunables. The tunable values are provided via
> > the GLIBC_TUNABLES env variable. Tests set it in makefiles using
> > 
> >   tst-foo-ENV = GLIBC_TUNABLES=tunable=value
> > 
> > This overwrites environment for this test, so if another env var is
> > set elsewhere, one of these changes would be lost. The correct way
> > should be to append to test's environment:
> > 
> >   tst-foo-ENV += GLIBC_TUNABLES=tunable=value
> > 
> > However, if two or more tunables need to be set for the same test,
> > the 'tunable=value' part should be appended to previously defined
> > GLIBC_TUNABLES env variable.
> > 
> > This commit adds 'tunable-add' that can be used to correctly append
> > another tunable to a test's environment. We also change tests in the
> > malloc and misc folder.
> > 
> > ---
> > base-commit: 9f5f18aab4
> > passes regression on aarch64 and x86-64
> 
> It is not clear to me why we need tunables to be composable.

The answer to this is right above in the commit message. If you need
more examples, here they are:

1) Testing memory tagging requires using the memtag tunable along with
   any other tunables that are already used by malloc and other tests.

2) Another example (that is not yet addressed in this patch but it's an
   easy extension), is that, when we run tests on a GCS (or BTI etc)
   system, we want to enable GCS for all tests by using something like

     GLIBC_TUNABLES=glibc.cpu.aarch64_gcs=1 make check

   However currently this would only apply to the tests that don't
   override environment (even if they do so for something other than
   tunables).

> I would 
> expect that cflags, ldflags, and any other build definition to might 
> require arch specific overrides.

This seems not related to the patch at all.

> 
> Also using a make rule to is not much ergonomic, it requires to trace all
> the previous ENV and other definitions to have the final tunable value.
> I think it is more clear to have clear place where the testing setup is
> set.
> 
> Maybe something move simpler would to have:
> 
>   tst-foo-TUNABLE1 = ...:
>   tst-foo-TUNABLE2 += ...
> 
> and then a rule to join all of them.

I might consider this, although I'm not sure what you mean by TUNABLE1
and TUNABLE2. This seems like a feature creep.

Please comment on the recent version of the patch, thanks.