Re: [Valgrind-developers] [PATCH] Linux: Inhibit tail calls in cancellable system calls

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

Hi Adhemerval,

On Tue, May 13, 2025 at 09:22:21AM +0100, Adhemerval Zanella Netto wrote:
> On 12/05/25 12:12, Mark Wielaard wrote:
> >> I am trying to check if patch to inline the cancellation wrappers [1]
> >> would help it, but I am not sure how exactly would handle stacktraces
> >> that should be artificial and only represented for debug information.
> > 
> > I got that patch [1] working so I could test it myself (only on x86_64
> > for now). How do you properly test a glibc installed in a non-default
> > location though? Currently I am doing something like:
> > 
> > export LD_LIBRARY_PATH=/usr/local/glibc/lib
> > /usr/local/glibc/lib/ld-linux-x86-64.so.2 memcheck/tests/sendmsg
> > 
> > This can also work with valgrind in between because it doesn't use
> > glibc dynamically itself. But it is not the easiest way to test
> > things.
> 
> I used -Wl,-dynamic-linker and -Wl,-rpath instead at configure:
> 
>   --enable-only64bit \
>   LDFLAGS="-Wl,--dynamic-linker,/path/to/glibc-build/testroot.pristine/lib/ld-linux-aarch64.so.1 \
>            -Wl,--rpath,/path/to/glibc-build/testroot.pristine/lib64"
>
> It won't use glibc startup object (*ct*.o), neither the headers; but
> using a recent systems it should not be a problem (the difference
> should be minimal).

O, thanks, that makes things much more convenient to test.

> > It isn't an "error" but any extra frames (either "real" or inlined) on
> > top of the function that does the actual system call causes existing
> > suppressions and test wrappers to no longer work. So valgrind is
> > responsible for filtering them out. For actual extra frames we now do
> > (since 3.25.0). If the extra syscall frame wrappers are inlined they
> > don't show up if no debuginfo/DWARF is available for glibc. But if it
> > is available we'll have to filter them out and/or don't look them up
> > for the top-level syscalls.
> > 
> > Selectively removing these inlined calls is a little fragile at the
> > moment in valgrind, since it is done at a later time than capturing
> > the backtrace addresses. So either we have to pass through that we are
> > handling a syscall at the moment and so don't want to "expand" the
> > top-level frame with any inlines. And/Or we match on the "magic"
> > inlined syscall cancel frames (everywhere).
> 
> If I understood correctly these seems to be an issue only for valgrind
> regression tests, right? If so, could this be handled solely on test
> validation?
> 
> Or does valgrind aims to hide such inlined calls on stacktrace reports
> as well?

We do aim to hide these in general since it invalidates any existing
suppressions people might be using. In theory we can of course not
guarantee these work between glibc versions, but for most glibc
syscall wrappers they are surprisingly stable. It also allows people
to generate new suppressions that should work across versions.

> > You could use __attribute__(__artificial__)) which should mark the
> > function with DW_AT_artificial. Valgrind doesn't know about this
> > attribute yet, but we could probably with some extra work.
> 
> Yeah, this is the first thing I tried to see if valgrind could handle
> it.  Doing this on glibc should be easy enough if you think it would
> be way to handle it on valgrind.

I currently have something working based on matching the function
names, but checking for DW_AT_artificial would be nicer. Also because
I think in general users are not interested in inlined artificial
functions in their stack traces. So it should be a general improvement
if we filter those out.

I post when I have a patch that does that (there is one tricky issue
if the abstract origin ends up in a dwz partial units, but that is
completely an internal valgrind DWARF reader issue, nothing to do with
glibc).

> >> [1] https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/azanella/cancel-wrappers-inline
> 

Thanks,

Mark