Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.27.0.RC2 is available for testing

[Mark W. <ma...@kl...>]

Hi Abhay,

On Sun, Apr 19, 2026 at 12:25:02AM +0530, Abhay Kandpal via Valgrind-developers wrote:
> I did testing again for valgrind-3.27.0.RC2.tar.bz2 on all setup like P10 LE, P9 LE/BE, P8 LE.
> 
> I found the results are mostly the same or slightly improved like for P9 BE, below cases are fixed in RC2.
> none/tests/fdleak_ipv4                           (stderr)
> none/tests/fdleak_ipv4_xml                       (stderr)
> none/tests/fdleak_ipv4_xml                       (stdout)
> 
> Versions used are the same as during RC1 testing which I already shared in my previous mail.

Great. Thanks.

> Technical Analysis:
> -------------------
> 
>  Valgrind's configure script detects AltiVec by parsing LD_SHOW_AUXV output:
> 
>     if env LD_SHOW_AUXV=1 true | grep ^AT_HWCAP | grep -q -w altivec
>     then
>         HWCAP_HAS_ALTIVEC='yes'
>     fi
> 
> 
> With glibc 2.41, LD_SHOW_AUXV prints human-readable capability names:
> 
>     AT_HWCAP: true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32
> 
> 
> With glibc 2.42, it only prints raw hex values:
> 
>     AT_HWCAP: 0xdc0065c2
> 
> 
> 
> The hex value 0xdc0065c2 does have the AltiVec bit set (bit 28 = 0x10000000), confirming
> that the hardware supports AltiVec.
> 
> 
> On BE systems, VGCONF_ARCH_SEC='ppc32' causes the ppc32 test suite to be built. Without HWCAP_HAS_ALTIVEC='yes',
> the -maltivec flag is omitted, and testVMX.c fails to compile.
> 
> LE systems are unaffected because VGCONF_ARCH_SEC is empty and ppc32 tests are not built.

Wow, interesting failure. And nice analysis.

> Workaround applied: I manually set HWCAP_HAS_ALTIVEC='yes' in the
> configure script on P10/P8 BE systems to unblock testing. After
> that, make and make regtest completed successfully. Results were
> same as RC1.

Thanks. Given there is a workaround, this is only with make regtest
and on a secondary arch which isn't super popular I think we won't try
to fix this before the release.
 
> I still need to investigate whether this change in glibc 2.42 is intentional.

Yes, this is slightly surprising change in behaviour for glibc
LD_SHOW_AUXV=1 I don't see anything in NEWS that would explain the
change.

> Currently, Valgrind's configure.ac handles only the string format, not hex. Do we need to handle this in configure.ac?

To be honest I think these AC_HWCAP_CONTAINS_FLAG usage in configure
are testing the wrong thing. They look whether the hardware supports some
feature, but then use it to provide a flag to gcc for building
something for that feature. So instead of a runtime check we should
add a compiler flag check (and then do the runtime check before
running the test).

> Otherwise valgrind 3.27.0 RC2 is good to go.

Thanks, I'll prep the final release now.

Cheers,

Mark