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

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

Hi Adhemerval,

On Fri, 2025-05-09 at 11:08 -0300, Adhemerval Zanella Netto wrote:
> On 25/04/25 19:06, Mark Wielaard wrote:
> > valgrind 3.25.0 have been released and is now in Fedora rawhide and
> > Fedora 42 with the new glibc syscall_cancel frames. The tail calls on
> > aarch64 still seem to be a problem for observability of the syscall
> > call stack.
> 
> 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.
> 
> With the patch applied, both x86_64 and aarch64 should inline the
> syscall_cancel and internal_syscall_cancel call, only required an
> extra __syscall_cancel_arch call for the case when the process it
> multithread.
> 
> On x86_64 it does shows as expected:
> 
> valgrind-git (x86_64)$ ./coregrind/valgrind memcheck/tests/sendmsg
> [...]
> ==2131145== Syscall param sendmsg(msg) points to uninitialised byte(s)
> ==2131145==    at 0x4972EE0: syscall_cancel (sysdep-cancel.h:83)
> ==2131145==    by 0x4972EE0: sendmsg (sendmsg.c:28)
> ==2131145==    by 0x4001332: main (sendmsg.c:46)
> ==2131145==  Address 0x1ffefff850 is on thread 1's stack
> ==2131145==  in frame #1, created by main (sendmsg.c:13)
> [...]
> 
> But on aarch64 it shows internal_syscall_cancel, which is indeed
> inlined:
> 
> valgrind-git (aarch64)$ ./coregrind/valgrind memcheck/tests/sendmsg
> [...]
> ==483437== Syscall param sendmsg(msg) points to uninitialised byte(s)
> ==483437==    at 0x49D250C: internal_syscall_cancel (sysdep-cancel.h:44)
> ==483437==    by 0x49D250C: syscall_cancel (sysdep-cancel.h:79)
> ==483437==    by 0x49D250C: sendmsg (sendmsg.c:28)
> ==483437==    by 0x4000B4B: main (sendmsg.c:46)
> ==483437==  Address 0x1ffefffaf8 is on thread 1's stack
> ==483437==  in frame #1, created by main (sendmsg.c:13)
> 
> I am not sure if valgrind consider this an error, nor if it should be
> valgrind or compiler to handle this correctly.  I am not aware of any
> attribute if can properly used to 'hide' internal_syscall_cancel in
> this case, or even if it makes sense.

Interesting. I would have assumed valgrind would have stripped out the
syscall_cancel calls. But it looks like we assume they always have a __
prefix (__syscall_cancel_arch, __internal_syscall_cancel and
__syscall_cancel). Apparently with glibc debuginfo installed it picks
up the inlined DWARF name. But we can filter those out too.

I think the above would work without glibc debuginfo installed because
then valgrind won't even know/see the inlined names.

Just to be sure, you are using the current git version of valgrind?
And you haven't explicitly installed that version? If so, could you try
the above with:

 ./vg-in-place memcheck/tests/sendmsg

vg-in-place makes sure the just compiled tools are used.

Thanks,

Mark