mirror of
https://github.com/bminor/binutils-gdb.git
synced 2025-11-16 04:24:43 +00:00
c87df013cb
I noticed something that seemed really strange with the i386 register
numbering.
In i386-linux-tdep.h we setup I386_LINUX_ORIG_EAX_REGNUM based on
I386_PKRU_REGNUM.
However, in i386-tdep.h, enum i386_regnum ends like this:
enum i386_regnum
{
...
I386_ZMM7H_REGNUM = I386_ZMM0H_REGNUM + 7,
I386_PKRU_REGNUM,
I386_PL3_SSP_REGNUM,
I386_FSBASE_REGNUM,
I386_GSBASE_REGNUM
};
So I386_LINUX_ORIG_EAX_REGNUM will have the same value as
I386_PL3_SSP_REGNUM.
The I386_PL3_SSP_REGNUM was added in commit:
commit 63b862be76
AuthorDate: Fri Mar 29 16:38:50 2019 +0100
CommitDate: Fri Aug 29 17:02:09 2025 +0000
gdb, gdbserver: Add support of Intel shadow stack pointer register.
And before that, I386_FSBASE_REGNUM and I386_GSBASE_REGNUM were added
in commit:
commit 1163a4b7a3
AuthorDate: Tue Mar 12 13:39:02 2019 -0700
CommitDate: Tue Mar 12 13:39:02 2019 -0700
Support the fs_base and gs_base registers on i386.
So the SSP overlap is new, but the fs/gs base overlap has existed for
years, so why did it not cause any problems?
I think the explanation is that on i386, the fs/gs base are only used
for FreeBSD, all the calls to i386_target_description that pass true
for the segments argument are from fbsd files. As a result, its fine
if there's numbering overlap between these i386 registers and some
Linux specific i386 registers.
OK, but what about the new SSP (shadow stack pointer) register?
I think in this case we would see problems, if the shadow stack was
supported for i386. Here's what the docs say:
The ‘org.gnu.gdb.i386.pl3_ssp’ feature is optional. It should
describe the user mode register ‘pl3_ssp’ which has 64 bits on amd64, 32
bits on amd64 with 32-bit pointer size (X32) and 32 bits on i386.
Following the restriction of the Linux kernel, only GDB for amd64
targets makes use of this feature for now.
And indeed, if we look for callers of x86_supply_ssp, which supplies
the shadow stack pointer register, this is only called from amd64
specific code, either the native register fetching, or the core file
loading. There's no calls from i386 code.
And so, again, we have register number overlap, but we avoid any
issues by not making use of these registers for i386 linux.
Here's my question: Is this super clever design aimed at saving 12
bytes (3 * 4-byte registers) of space in the i386 regcache? Or is
this an accident where we happen to have gotten lucky?
If it's the first, then I really think there should be some comments
explaining what's going on.
If it's the second, then maybe we should fix this before it trips us
up?
This commit takes the second approach by doing the following:
1. In i386-tdep.h move all the *_NUM_REGS constants to be members of
'enum i386_regnum'. The I386_NUM_REGS value can be automatically
calculated based off the (current) last enum entry, and the
other *_NUM_REGS constants are calculated just as they previously
were, but are moved to keep them all together.
2. In i386-linux-tdep.h, I386_LINUX_ORIG_EAX_REGNUM and
I386_LINUX_NUM_REGS are moved into a new enum i386_linux_regnum,
the name of which is inspired by i386_regnum with the addition
of the linux tag. The first entry in this new enum starts from
I386_NUM_REGS rather than I386_PKRU_REGNUM. The
I386_LINUX_NUM_REGS will be calculated automatically by the
compiler.
3. In amd64-linux-nat.c, I extend amd64_linux_gregset32_reg_offset
so that it now has entries for the 3 registers that are no longer
aliasing, this stops an assert from the end of the file
triggering:
gdb_assert (ARRAY_SIZE (amd64_linux_gregset32_reg_offset)
== amd64_native_gregset32_num_regs);
As I386_LINUX_NUM_REGS has now increased by 3.
4. Given (3) I wondered why there was no assert being triggered from
the i386 code as i386_linux_gregset_reg_offset, in i386-linux-tdep.c
is clearly also wrong now.
So, In i386-linux-tdep.c I've added a new assertion at the end of
the file.
And then I've fixed i386_linux_gregset_reg_offset by adding the 3
new registers.
With these changes made I believe that the register number for the
$orig_eax register on i386 GNU/Linux targets should no longer be
aliasing with the SSP register.
For the reasons given above, I don't think this fixes any actual bugs,
it's more just a, lets not have unnecessary, and undocumented,
register number aliasing.
This change is visible using 'maint print registers', check out the
register number of $orig_eax before and after, it should now be +3
from where it was (changed from 72 to 75).
I did worry briefly about gdbservers that might not support XML target
descriptions and instead rely on a fixed GDB register numbering.
Though, if I'm honest, I have very little sympathy for such gdbservers
these days. Still, they could, potentially be tripped up by this
change. However, this is not the first time in recent years that the
value of I386_LINUX_ORIG_EAX_REGNUM has changed. This commit also
adjusted the register number:
commit 51547df62c
Date: Wed Feb 1 12:22:27 2017 +0100
Add support for Intel PKRU register to GDB and GDBserver.
And I'm not aware of any bug reports that came from this, we certainly
didn't feel the need to adjust the register number back again. So I'm
guessing that this renumbering will also go without issue.
Other than that, there should be no user visible changes after this
commit.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
65 lines
2.3 KiB
C
65 lines
2.3 KiB
C
/* Target-dependent code for GNU/Linux x86.
|
|
|
|
Copyright (C) 2002-2025 Free Software Foundation, Inc.
|
|
|
|
This file is part of GDB.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
#ifndef GDB_I386_LINUX_TDEP_H
|
|
#define GDB_I386_LINUX_TDEP_H
|
|
|
|
#include "gdbsupport/x86-xstate.h"
|
|
#include "i386-tdep.h"
|
|
|
|
/* Additional register numbers for i386 Linux, these are in addition to
|
|
the register numbers found in 'enum i386_regnum', see i386-tdep.h. */
|
|
|
|
enum i386_linux_regnum
|
|
{
|
|
/* STOP! The values in this enum are numbered after the values in the
|
|
enum i386_regnum. New entries should be placed after the ORIG_EAX
|
|
entry. */
|
|
|
|
/* Register number for the "orig_eax" pseudo-register. GDB needs access
|
|
to this register to be able to properly restart system calls when
|
|
necessary (see i386-linux-tdep.c). If this pseudo-register contains a
|
|
value >= 0 it is interpreted as the system call number that the kernel
|
|
is supposed to restart. */
|
|
I386_LINUX_ORIG_EAX_REGNUM = I386_NUM_REGS,
|
|
|
|
/* Total number of registers for GNU/Linux. */
|
|
I386_LINUX_NUM_REGS
|
|
|
|
/* STOP! Add new entries before I386_LINUX_NUM_REGS. */
|
|
};
|
|
|
|
/* Read the XSAVE extended state xcr0 value from the ABFD core file.
|
|
If it appears to be valid, return it and fill LAYOUT with values
|
|
inferred from that value.
|
|
|
|
Otherwise, return 0 to indicate no state was found and leave LAYOUT
|
|
untouched. */
|
|
extern uint64_t i386_linux_core_read_xsave_info (bfd *abfd,
|
|
x86_xsave_layout &layout);
|
|
|
|
/* Implement the core_read_x86_xsave_layout gdbarch method. */
|
|
extern bool i386_linux_core_read_x86_xsave_layout (struct gdbarch *gdbarch,
|
|
bfd &cbfd,
|
|
x86_xsave_layout &layout);
|
|
|
|
extern int i386_linux_gregset_reg_offset[];
|
|
|
|
#endif /* GDB_I386_LINUX_TDEP_H */
|