Re: [Valgrind-developers] extra syscall_cancel frames

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

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

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

But doing the check for whether the top frames are inside the
__syscall_cancel symbol code ranges shouldn't be too expensive to do
always. We would lookup the code ranges when loading glibc once and
doing the address comparison should be cheap (we do something similar
for the frames "below main").

Cheers,

Mark