extra syscall_cancel frames

[Florian Weimer]

* Mark Wielaard:

>> I think __internal_syscall_cancel should get inlined into
>> __syscall_cancel.
>
> It isn't, I double checked with gdb and there are always two extra
> frames on top of the call stack.

Oh, right, it's not static.

>> And this commit fixed it:
>> 
>> commit 89b53077d2a58f00e7debdfe58afabe953dac60d
>> Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
>> Date:   Tue Jun 25 16:17:44 2024 -0300
>> 
>>     nptl: Fix Race conditions in pthread cancellation [BZ#12683]
>
> Interesting, so this is actually in 2.41? I should try the fedora 42
> beta then. Do you happen to know whether people/distros have
> backported this to earlier releases?

We're probably going to backport it all the way to Fedora 40/RHEL 10,
but perhaps not before Fedora 40 goes out of support.

> I think these extra __*syscall*cancel* frames are somewhat confusing
> to the user and messes up existing suppressions. They also cause
> trouble for the valgrind regtests.
>
> I think the solution for valgrind is to just skip the top (two) frames
> if they match the __*syscall*cancel* symbol address ranges. And we
> only need to do that when we are creating a backtrace from a valgrind
> syscall wrapper.
>
> Looking at the glibc symtab I see four function symbol matching that
> pattern:
>
>  2140: 0000000000079840     51 FUNC    LOCAL  DEFAULT        4 __syscall_cancel_arch
>  3561: 000000000006daf0     64 FUNC    LOCAL  DEFAULT        4 __syscall_cancel
>  3700: 000000000006da60    140 FUNC    LOCAL  DEFAULT        4 __internal_syscall_cancel
>  4566: 000000000006da00     87 FUNC    LOCAL  DEFAULT        4 __syscall_do_cancel
>
> Can we rely on those names (and assume there are only 4) or is it
> better to be flexible and just create a dynamic array for any glibc
> local function that matches the __*syscall*cancel* pattern?

I don't think __syscall_do_cancel will need suppressions?  It just
starts unwinding.

The names should remain fairly stable.  We should add comments to the
sources mentioning the valgrind dependency.  Adhemerval, what do you
think?

Does it matter for valgrind's purposes that those aren't dynamic
symbols?  In Fedora, we try to accommodate valgrind and similar tools
and preserve the static symbol table, but not all distributions do this.

Thanks,
Florian