Re: [Valgrind-developers] extra syscall_cancel frames

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

On 21/03/25 09:26, 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.
> 
> 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.  We get lucky on x86-64 due to the parameter
> passing on the stack:
> 
> 0000000000000000 <__GI___libc_write>:
>    0:	f3 0f 1e fa          	endbr64
>    4:	48 83 ec 10          	sub    $0x10,%rsp
>    8:	48 63 ff             	movslq %edi,%rdi
>    b:	45 31 c9             	xor    %r9d,%r9d
>    e:	45 31 c0             	xor    %r8d,%r8d
>   11:	6a 01                	push   $0x1
>   13:	31 c9                	xor    %ecx,%ecx
>   15:	e8 00 00 00 00       	call   1a <__GI___libc_write+0x1a>
> 			16: R_X86_64_PLT32	__syscall_cancel-0x4
>   1a:	48 83 c4 18          	add    $0x18,%rsp
>   1e:	c3                   	ret
> 
> But on POWER10, we have:
> 
> 0000000000000000 <__GI___libc_write>:
>    0:   04 00 20 39     li      r9,4
>    4:   00 00 00 39     li      r8,0
>    8:   00 00 e0 38     li      r7,0
>    c:   00 00 c0 38     li      r6,0
>   10:   00 00 00 48     b       10 <__GI___libc_write+0x10>
>                         10: R_PPC64_REL24_NOTOC __syscall_cancel
> 
> So I think the interceptors will remain broken there even with call
> frame filtering.
> 
> Should we inhibit the tail call on the glibc side?

The tail-call is a nice optimization, is this really necessary to
avoid it?

Another possibility is to make inline internal_syscall_cancel on
each cancellation entrypoint.  It will increase the code size a bit,
but it should be doable.