mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 12:34:43 +00:00
fbfb29b304
On openSUSE Tumbleweed x86_64, with target board unix/-m32 and test-case
gdb.reverse/recvmsg-reverse.exp, I run into:
...
(gdb) continue^M
Continuing.^M
Process record and replay target doesn't support syscall number 360^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0xf7fc5575 in __kernel_vsyscall ()^M
(gdb) FAIL: $exp: continue to breakpoint: marker2
...
The syscall number 360 in i386 is for syscall socketpair, as we can see in
arch/x86/entry/syscalls/syscall_32.tbl:
...
<number> <abi> <name> <entry point>
360 i386 socketpair sys_socketpair
...
Function i386_canonicalize_syscall assumes that any syscall below 500 maps to
an identically valued enum in enum gdb_syscall:
...
static enum gdb_syscall
i386_canonicalize_syscall (int syscall)
{
enum { i386_syscall_max = 499 };
if (syscall <= i386_syscall_max)
return (enum gdb_syscall) syscall;
else
return gdb_sys_no_syscall;
}
...
However, that's not the case. The value of gdb_sys_socketpair is not 360,
but 512:
...
enum gdb_syscall {
...
gdb_sys_getrandom = 355,
gdb_sys_statx = 383,
...
gdb_sys_socketpair = 512,
...
Consequently, when record_linux_system_call is called with
syscall == i386_canonicalize_syscall (360), we hit the default case here:
....
switch (syscall)
{
...
default:
gdb_printf (gdb_stderr,
_("Process record and replay target doesn't "
"support syscall number %d\n"), syscall);
return -1;
break;
}
...
rather than hitting the case for gdb_sys_socketpair.
I initially wrote a trivial fix for this, changing the value of
gdb_sys_socketpair to 360. However, Andreas Schwab pointed out that there are
other functions (ppc_canonicalize_syscall and s390_canonicalize_syscall) that
make assumptions about specific values of enum gdb_syscall, and fixing this
for i386 may break things for ppc or s390.
So instead, I decided to rewrite i386_canonicalize_syscall to match the
approach taken in aarch64_canonicalize_syscall, which allows
gdb_sys_socketpair to keep the same value.
So, fix this by:
- adding a new table file gdb/i386-syscalls.def, using a SYSCALL entry for
each syscall, generated from arch/x86/entry/syscalls/syscall_32.tbl,
- using gdb/i386-syscalls.def to define enum i386_syscall, and
- using macros SYSCALL_MAP, SYSCALL_MAP_RENAME and UNSUPPORTED_SYSCALL_MAP to
define the mapping from enum i386_syscall to enum gdb_syscall in
i386_canonicalize_syscall.
I've created the mapping as follows:
- I used arch/x86/entry/syscalls/syscall_32.tbl to generate an initial mapping
using SYSCALL_MAP for each syscall,
- I attempted to compile this and used the compilation errors about
non-existing gdb_sys_ values to change those entries to
UNSUPPORTED_SYSCALL_MAP, which got me a compiling version,
- I reviewed the UNSUPPORTED_SYSCALL_MAP entries, changing to
SYSCALL_MAP_RENAME where necessary,
- I then reviewed syscalls below 500 that mapped to a gdb_syscall value below
500, but not the same, and fixed those using SYSCALL_MAP_RENAME, and
- reviewed the mapping for gdb_syscall entries >= 500.
On the resulting mapping, I was able to do the following sanity check:
...
for (int i = 0; i < 500; ++i)
{
int res = i386_canonicalize_syscall (i);
if (res == i)
continue;
if (res == -1)
continue;
if (res >= 500)
continue;
gdb_assert_not_reached ("");
}
}
...
to make sure that any syscall below 500 either:
- maps to the same number,
- is unsupported, or
- maps to a number >= 500.
Coming back to our original problem, the socket pair syscall is addressed by
an entry:
...
SYSCALL_MAP (socketpair);
...
which maps i386_sys_socketpair (360) to gdb_sys_socketpair (512).
Tested on x86_64-linux with target board unix/-m32.
Approved-By: Guinevere Larsen <guinevere@redhat.com>
PR tdep/32770
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32770
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.