Re: [Valgrind-developers] extra syscall_cancel frames

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

Hi Florian,

On Fri, 2025-03-21 at 14:14 +0100, Florian Weimer wrote:
> * Mark Wielaard:
> > On Fri, 2025-03-21 at 13:26 +0100, Florian Weimer wrote:
> > > 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?

Both. (User) suppressions work on the backtrace at the point of issue
reported. So in general they need the top of the stack symbol name be
the same to work (you can have regexp in the suppression, but normally
you wouldn't use them for top of stack). So what valgrind (core) would
do is filter out the top (two) extra *syscall_cancel* frames so the top
of stack would be the "normal" glibc function as if that called the
syscall directly.

> 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.

Aha, yes. In both cases my proposal would be to filter out the top two
call frames and make #2 the top of stack (the new #0). So the second
would indeed be preferred.

Thanks,

Mark