extra syscall_cancel frames
Florian Weimer
fweimer@redhat.com
Fri Mar 21 12:26:03 GMT 2025
* 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
More information about the Libc-alpha
mailing list