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

[Adhemerval Z. N. <adh...@li...>]

On 09/05/25 11:24, Mark Wielaard wrote:
> 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.

I have tested only with a unstriped glibc build, so I am not sure how 
it would play with debuginfo.

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

I took care to export VALGRIND_LIB to the proper location, but the results
with vg-in-place are the same.

> 
> Thanks,
> 
> Mark