extra syscall_cancel frames

[Mark Wielaard]

Hi,

With latest glibc on fedora rawhide (glibc-2.40.9000-37.fc43.x86_64) I
am seeing some extra frames in the call stack that I wonder whether to
specially handle in valgrind.

Before we would report on some bad syscall argument like:

==1929378== Syscall param sendmsg(msg) points to uninitialised byte(s)
==1929378==    at 0x4971514: sendmsg (sendmsg.c:28)
==1929378==    by 0x40128B: main (sendmsg.c:46)
==1929378==  Address 0x1ffefff640 is on thread 1's stack
==1929378==  in frame #1, created by main (sendmsg.c:13)

Now it looks like:

==2670784== Syscall param sendmsg(msg) points to uninitialised byte(s)
==2670784==    at 0x48D9AE6: __internal_syscall_cancel (cancellation.c:64)
==2670784==    by 0x48D9B03: __syscall_cancel (cancellation.c:75)
==2670784==    by 0x49628F0: sendmsg (sendmsg.c:28)
==2670784==    by 0x4005CB: main (sendmsg.c:46)
==2670784==  Address 0x1ffeffff40 is on thread 1's stack
==2670784==  in frame #3, created by main (sendmsg.c:13)

Which I think is not as helpful to the user.
So I am wondering whether those extra frames should be handled
specially in valgrind and filtered out. But were these extra stack
frames added explicitly? And are they easily detected (symbol name
starting with __ and containing syscall might be a good hearistic)?

Thanks,

Mark