glibc 2.33.9000 version checks and in memory file name change

[Mark Wielaard <mark@klomp.org>]

Hi,

valgrind is kind of special and does various things it really shouldn't
do, but... There is one change in particular in 2.34 pre-releases that
is causing us some headaches. It took a bit of time to understand that
this innocent looking changes had an impact:

   * Previously, glibc installed its various shared objects under
   versioned file names such as libc-2.33.so.  The ABI sonames
   (e.g., libc.so.6) were provided as symbolic links.  Starting
   with glibc 2.34, the shared objects are installed under their
   ABI sonames directly, without symbolic links.  This increases
   compatibility with distribution package managers that delete
   removed files late during the package upgrade or downgrade
   process.

This has an impact on anything that uses in-process mapped file names.
For example most programs using backtraces used to report something like:

#0  0x00007fd73bdcbaea     __GI___clock_nanosleep - /usr/lib64/libc-2.33.so
#1  0x00007fd73bdd0d57 - 1 __GI___nanosleep - /usr/lib64/libc-2.33.so
#2  0x000055988e913a00 - 1 main - /usr/bin/sleep
#3  0x00007fd73bd2bb75 - 1 __libc_start_main - /usr/lib64/libc-2.33.so
#4  0x000055988e913bbe - 1 _start - /usr/bin/sleep

But now report:

#0  0x00007f070b8a2c1a     __GI___clock_nanosleep - /usr/lib64/libc.so.6
#1  0x00007f070b8a7997 - 1 __GI___nanosleep - /usr/lib64/libc.so.6
#2  0x000055657fbf0a00 - 1 main - /usr/bin/sleep
#3  0x00007f070b7f57e0 - 1 __libc_start_call_main - /usr/lib64/libc.so.6
#4  0x00007f070b7f588c - 1 __libc_start_main_impl - /usr/lib64/libc.so.6
#5  0x000055657fbf0bb5 - 1 _start - /usr/bin/sleep

Unfortunately valgrind suppressions are based on the file name reported
in the backtrace when valgrind reports an issue. For example we have
some standard suppressions like:

{
   helgrind-glibc-io-xsputn-mempcpy
   Helgrind:Race
   fun:__GI_mempcpy
   fun:_IO_*xsputn*
   obj:*/lib*/libc-2.*so*
}

That tells to suppress an Helgrind Race condition if the backtrace
originated for an in memory object file matching */lib*/libc-2.*so*.
This suppression fails now since /usr/lib64/libc.so.6 doesn't match
that pattern.

I wonder if there are other programs which might depend on the in
memory file name of glibc and might be impacted by this change.

Now we can update our default suppressions and will do so.

Unfortunately our current mechanism for doing that relies on a
configure check for the glibc version. Specifically we check whether
features.h defines __GLIBC__ __GLIBC_MINOR__ and construct the glibc
version from that. But current development versions of glibc (like
Fedora rawhides glibc-2.33.9000) still report __GLIBC_MINOR__ as 33.

Is there a way to detect this is really 2.33.9000 aka almost 2.34? Or
could you up the __GLIBC_MINOR__ already now that people are starting
to ship test versions like 2.33.9000?

Thanks,

Mark