Re: [Valgrind-developers] extra syscall_cancel frames

[Florian W. <fw...@re...>]

* Mark Wielaard:

> Hi,
>
> On Fri, 2025-03-21 at 13:26 +0100, Florian Weimer wrote:
>> * Florian Weimer:
>> 
>> > 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.
>
> Do you mean, should they appear in .symtab and should .symtab be
> preserved (not stripped out)? Yes, that is how I imagine we lookup the
> relevant function code ranges. We rely on finding symbtab symbols for a
> couple of things in valgrind. If the symtab isn't available we would
> simply not be able to strip out the top two frames (or name them).

Right.  The question is if we need to make this symbols dynamic (undera
GLIBC_PRIVATE version).

>> One more thing: If I understand things correctly, valgrind absolutely
>> needs to see the original system-calling function on the stack for the
>> suppressions to work.
>
> It is not absolutely necessary, but it would be a nice optimization.
> valgrind knows when it is handling a syscall so if it has to provide a
> backtrace during that processing it can easily skip the first (two)
> frames.

So is this just cosmestic about error reporting?  I thought you'd need
the function name matching for the suppressions to work?

With a tail call here, there is no function name to match:

#0  0x00007ffff789f784 in __internal_syscall_cancel (a1=<optimized out>, 
    a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, 
    a5=<optimized out>, a6=<optimized out>, nr=<optimized out>)
    at cancellation.c:64
#1  0x00007ffff789f820 in __syscall_cancel (a1=<optimized out>, 
    a2=<optimized out>, a3=<optimized out>, a4=<optimized out>, 
    a5=<optimized out>, a6=<optimized out>, nr=<optimized out>)
    at cancellation.c:75
#2  0x00007ffff7d8175c in ?? () from /lib64/libtcl8.6.so

With the patch I just posted, we have:

#0  0x00007ffff789f784 in __internal_syscall_cancel (a1=<optimized out>, 
    a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0, 
    a6=a6@entry=0, nr=nr@entry=3) at cancellation.c:64
#1  0x00007ffff789f820 in __syscall_cancel (a1=<optimized out>, 
    a2=<optimized out>, a3=<optimized out>, a4=a4@entry=0, a5=a5@entry=0, 
    a6=a6@entry=0, nr=nr@entry=3) at cancellation.c:75
#2  0x00007ffff7932b50 in __GI___libc_read (fd=<optimized out>, 
    buf=<optimized out>, nbytes=<optimized out>)
    at ../sysdeps/unix/sysv/linux/read.c:26
#3  0x00007ffff7d8175c in ?? () from /lib64/libtcl8.6.so

I hope that clarifies my concern.

Thanks,
Florian