Re: glibc 2.33.9000 version checks and in memory file name change

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 19/07/2021 06:18, Mark Wielaard wrote:
> Hi,
> 
> On Wed, Jul 14, 2021 at 01:55:27PM -0300, Adhemerval Zanella wrote:
>> On 09/07/2021 13:37, Mark Wielaard wrote:
>>> 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.
>>
>> I am not sure, but relying on such naming scheme is fragile in principle:
>> although the installation did use the embedded the version in the 
>> installed filename nothing preventes the distribution to rename it to
>> something complete different (since the DT_NEEDED will still point to
>> libc.so.6).
> 
> Yes, it would be nicer to have used the so name, but people are more
> familiar with the actual file name. It also used to be more
> architecture independent. Because of the symlinks ld.so was named the
> same on all arches. I certainly understand this was just by accident
> and we shouldn't have relied on it, but...

We really care about ABI stability and since this is accomplished by
setting the expected soname on DT_NEEEDED, I think adding another
constrain, such the installed filename, does not really add much here.
The potential breakage is minimum imho and could be mitigated by using
a more expressive filter (such as the one I suggested) if filename is
really important by the project.

> 
>>> 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.
>>
>> What kind of regular expression does valgrind suppression mechanism
>> support? Does it mimic the shell expansion used on glob(), for instance,
>> or is it something more restrict?
> 
> It only knows about * (zero or more) and ? (zero or one) chars.
> 
>>> 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?
>>
>> We now moved all libpthread/librt/libdl symbols to libc.so, so if you
>> must detect 2.34 glibc you may try use pthread_create without linking
>> to -lpthread.
> 
> Thanks, that is a nice check. I used that for now.
> https://bugs.kde.org/show_bug.cgi?id=439590
> 
>> Usually we do follow the release procedure to just bump
>> de version to 2.34 once the release is actually done.
> 
> Understood, and it is too late to change that for this release.  But
> maybe for the next features.h could be changed at the freeze point
> instead of at release? Then people will test against the actual
> release number.
> 

I don't have a strong opinion, maybe we could bump it on slushy freeze
that usually happens 4 weeks prior release.  Carlos, what do you think
about changing it to the next release?