On Mon, Jul 3, 2023 at 12:31 AM John Reiser <jrei...@bitwagon.com> wrote:
> Please show the complete output of "uname -a".
> In the linux git source code repository
> url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> there is no git tag "v3.10.0"; only "v3.10" and "v3.10.1", "v3.10.2", etc.
Yes, this distribution is based on a modified kernel and not on the
official one.
The full name from uname is 3.10.0-1150.15.2cpx86_64
> After checking out the code via "git checkout v3.10.1", then "grep -sr
> setprocns ."
> shows that the linux source code has no lines that contain "setprocns".
> So there is an error in part of your claim.
Indeed, it seems that this syscall is specific to this distribution -
upon encountering
the problem I went straight to distribution's kernel source to check
the syscall table
and didn't realize that it may be different from the vanilla kernel.
After comparing
distribution's syscall table to original 3.10.x sources I see that the
distribution ported
some of the syscalls from later kernels (highest syscall on 3.10.x is 350, while
the distribution has syscalls with higher numbers - which are not even
consecutive),
and added this one new custom syscall.
This explains why valgrind 3.10.0 works on this distribution - it just
doesn't implement
wrappers for syscalls higher than 355, and therefore there is no
collision with a custom
syscall which hijacks syscall number from a syscall that in later
kernel version is
used for a different syscall (preadv2).
> 2. The valgrind syscall table is in coregrind/m_syswrap/syswrap-x86-linux.c
> and syswrap-amd64-linux.c. Therefore, modify the source code of valgrind
> to call utsname() during initialization, and alter the table
> static SyscallTableEntry syscall_table[] = { ... };
> accordingly. Probably 'static' must be removed. Also, 'const' should
> be removed if necessary. [Why isn't the table 'const' in the first
> place?]
Thanks for the pointer. I just commented out the line for the mentioned syscall
number from valgrind's syscall table, and this workaround was enough to solve
the problem. Since the custom syscall doesn't modify its parameters and doesn't
seem to write anything in user space, it seems that writing a wrapper
for it is not
strictly necessary - or very useful for that matter, since in any case
it won't be
possible to submit a valgrind patch for the problem.
Beyond this problem, maybe it could be useful if upon encountering an impossible
problem (the one when valgrind writes: "valgrind: the 'impossible' happened"),
valgrind will send a user to read the file README_MISSING_SYSCALL_OR_IOCTL
in addition to telling him to read FAQ. Had I been aware of this file
before, I would
have known how to solve the problem myself.
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
