Re: [Valgrind-developers] extra syscall_cancel frames

[Florian W. <fw...@re...>]

* 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?

Thanks,
Florian