On Thu, 2022-07-28 at 22:22 +0100, Tom Hughes via Valgrind-users wrote:
> On 28/07/2022 21:39, Mark Roberts wrote:
> > I recently upgraded from Ubutu 20.04 to 22.04 and am now getting a
> > new
> > error message from Valgrind:
> >
> > --915-- WARNING: unhandled amd64-linux syscall: 334
> >
> > --915-- You may be able to write your own handler.
> >
> > --915-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> >
> > --915-- Nevertheless we consider this a bug. Please report
> >
> > --915-- it at http://valgrind.org/support/bug_reports.html
> > <http://valgrind.org/support/bug_reports.html>.
> >
> > Using same version of Valgrind as before (3.17).
> >
> > Any ideas as to what’s happening?
>
> Yes, your libc has started trying to use rseq.
>
> It's harmless - the next version of valgrind will silently
> reject it with ENOSYS which is what is happening now anyway
> just with a warning.
Where the next version of valgrind is 3.19.0 which is already released
(in April). So you might just want to upgrade your valgrind.
If you want to backport to older versions then the commit that got rid
of the warning was:
commit 1024237358f01009fe233cb1294f3b8211304eaa
Author: Mark Wielaard <m...@klomp.org>
Date: Fri Dec 10 17:41:59 2021 +0100
Implement linux rseq syscall as ENOSYS
This implements rseq for amd64, arm, arm64, ppc32, ppc64,
s390x and x86 linux as ENOSYS (without warning).
glibc will start using rseq to accelerate sched_getcpu, if
available. This would cause a warning from valgrind every
time a new thread is started.
Real rseq (restartable sequences) support is pretty hard, so
for now just explicitly return ENOSYS (just like we do for clone3).
https://sourceware.org/pipermail/libc-alpha/2021-December/133656.html
Cheers,
Mark
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
