Right now, gdbsupport/common-regcache.h contains two abstractons for a
regcache. An opaque type `regcache` (gdb and gdbserver both have their
own regcache that is the concrete version of this) and an abstract base
class `reg_buffer_common`, that is the base of regcaches on both sides.
These abstractions allow code to be written for both gdb and gdbserver,
for instance in the gdb/arch sub-directory.
However, having two
different abstractions is impractical. If some common code has a regcache,
and wants to use an operation defined on reg_buffer_common, it can't.
It would be better to have just one. Change all instances of `regcache
*` in gdbsupport/common-regcache.h to be `reg_buffer_common *`, then fix
fallouts.
Implementations in gdb and gdbserver now need to down-cast (using
gdb::checked_static_cast) from reg_buffer_common to their concrete
regcache type. Some of them could be avoided by changing free functions
(like regcache_register_size) to be virtual methods on
reg_buffer_common. I tried it, it seems to work, but I did not include
it in this series to avoid adding unnecessary changes.
Change-Id: Ia5503adb6b5509a0f4604bd2a68b4642cc5283fd
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
This changes gdb to use the C++17 [[fallthrough]] attribute rather
than special comments.
This was mostly done by script, but I neglected a few spellings and so
also fixed it up by hand.
I suspect this fixes the bug mentioned below, by switching to a
standard approach that, presumably, clang supports.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159
Approved-By: John Baldwin <jhb@FreeBSD.org>
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Pedro Alves <pedro@palves.net>
SME2 defines a new 512-bit register named ZT0, and it is only available
if SME is also supported. The ZT0 state is valid only if the SVCR ZA bit
is enabled. Otherwise its contents are empty (0).
The target description is dynamic and gets generated at runtime based on the
availability of the feature.
Validated under Fast Models.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
This patch enables dumping SME state via gdb's gcore command and also
enables gdb to read SME state from a core file generated by the Linux
Kernel.
Regression-tested on aarch64-linux Ubuntu 22.04/20.04.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with
variable sizes. It also exposes a new mode called streaming mode.
Similarly to SVE, the ZA register size is dictated by a vector length, but the
SME vector length is called streaming vetor length. The total size for
ZA in a given moment is svl x svl.
In streaming mode, the SVE registers have their sizes based on svl rather than
the regular vector length (vl).
The feature detection is controlled by the HWCAP2_SME bit, but actual support
should be validated by attempting a ptrace call for one of the new register
sets: NT_ARM_ZA and NT_ARM_SSVE.
Due to its large size, the ZA register is exposed as a vector of bytes, but we
introduce a number of pseudo-registers that gives various different views
into the ZA contents. These can be arranged in a couple categories: tiles and
tile slices.
Tiles are matrices the same size or smaller than ZA. Tile slices are vectors
which map to ZA's rows/columns in different ways.
A new dynamic target description is provided containing the ZA register, the SVG
register and the SVCR register. The size of ZA, like the SVE vector registers,
is based on the vector length register SVG (VG for SVE).
This patch enables SME register support for gdb.
[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture
Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com>
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Before actual vlen handling, fix the riscv_gdbarch_features hashing
function based on the actual valid range of vlen. In bytes, vlen is 0,
or 4 <= xlen <= 8192.
Before actual vlen handling, this commit fixes its description to allow vlen
less than 16 (but 4 or greater), to support vector subset extensions for
embedded environment ('Zve32*').
At the moment GDB only handles pointer authentication (pauth) for userspace
addresses and if we're debugging a Linux-hosted program.
The Linux Kernel can be configured to use pauth instructions for some
additional security hardening, but GDB doesn't handle this well.
To overcome this limitation, GDB needs a couple things:
1 - The target needs to advertise pauth support.
2 - The hook to remove non-address bits from a pointer needs to be registered
in aarch64-tdep.c as opposed to aarch64-linux-tdep.c.
There is a patch for QEMU that addresses the first point, and it makes
QEMU's gdbstub expose a couple more pauth mask registers, so overall we will
have up to 4 pauth masks (2 masks or 4 masks):
pauth_dmask
pauth_cmask
pauth_dmask_high
pauth_cmask_high
pauth_dmask and pauth_cmask are the masks used to remove pauth signatures
from userspace addresses. pauth_dmask_high and pauth_cmask_high masks are used
to remove pauth signatures from kernel addresses.
The second point is easily addressed by moving code around.
When debugging a Linux Kernel built with pauth with an unpatched GDB, we get
the following backtrace:
#0 __fput (file=0xffff0000c17a6400) at /repos/linux/fs/file_table.c:296
#1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
#2 0x30008000080ade30 [PAC] in ?? ()
#3 0x30d48000080ade30 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
With a patched GDB, we get something a lot more meaningful:
#0 __fput (file=0xffff0000c1bcfa00) at /repos/linux/fs/file_table.c:296
#1 0xffff8000082bd1f0 in ____fput (work=<optimized out>) at /repos/linux/fs/file_table.c:348
#2 0xffff8000080ade30 [PAC] in task_work_run () at /repos/linux/kernel/task_work.c:179
#3 0xffff80000801db90 [PAC] in resume_user_mode_work (regs=0xffff80000a96beb0) at /repos/linux/include/linux/resume_user_mode.h:49
#4 do_notify_resume (regs=regs@entry=0xffff80000a96beb0, thread_flags=4) at /repos/linux/arch/arm64/kernel/signal.c:1127
#5 0xffff800008fb9974 [PAC] in prepare_exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:137
#6 exit_to_user_mode (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:142
#7 el0_svc (regs=0xffff80000a96beb0) at /repos/linux/arch/arm64/kernel/entry-common.c:638
#8 0xffff800008fb9d34 [PAC] in el0t_64_sync_handler (regs=<optimized out>) at /repos/linux/arch/arm64/kernel/entry-common.c:655
#9 0xffff800008011548 [PAC] in el0t_64_sync () at /repos/linux/arch/arm64/kernel/entry.S:586
Backtrace stopped: Cannot access memory at address 0xffff80000a96c0c8
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
PR gdb/28947
The address_significant gdbarch setting was introduced as a way to remove
non-address bits from pointers, and it is specified by a constant. This
constant represents the number of address bits in a pointer.
Right now AArch64 is the only architecture that uses it, and 56 was a
correct option so far.
But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes
from the address space to store the required information. We could also have
cases where we're using both PAuth and MTE.
We could adjust the constant to 48 to cover those cases, but this doesn't
cover the case where GDB needs to sign-extend kernel addresses after removal
of the non-address bits.
This has worked so far because bit 55 is used to select between kernel-space
and user-space addresses. But trying to clear a range of bits crossing the
bit 55 boundary requires the hook to be smarter.
The following patch renames the gdbarch hook from significant_addr_bit to
remove_non_address_bits and passes a pointer as opposed to the number of
bits. The hook is now responsible for removing the required non-address bits
and sign-extending the address if needed.
While at it, make GDB and GDBServer share some more code for aarch64 and add a
new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp.
Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947
Approved-By: Simon Marchi <simon.marchi@efficios.com>
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and
it will be added to the existing NT_ARM_TLS register set. Kernel patches are
being reviewed here:
https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/
From GDB's perspective, we handle it in a similar way to the existing TPIDR
register. But we need to consider cases of systems that only have TPIDR and
systems that have both TPIDR and TPIDR2.
With that in mind, the following patch adds the required code to support
TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a
dynamically-generated target description as opposed to a static target
description containing only TPIDR.
That means we can remove the gdb/features/aarch64-tls.xml file and replace the
existing gdb/features/aarch64-tls.c auto-generated file with a new file that
dynamically generates the target description containing either TPIDR alone or
TPIDR and TPIDR2.
In the future, when *BSD's start to support this register, they can just
enable it as is being done for the AArch64 Linux target.
The core file read/write code has been updated to support TPIDR2 as well.
On GDBserver's side, there is a small change to the find_regno function to
expose a non-throwing version of it.
It always seemed strange to me how find_regno causes the whole operation to
abort if it doesn't find a particular register name. The patch moves code
from find_regno into find_regno_no_throw and makes find_regno call
find_regno_no_throw instead.
This allows us to do register name lookups to find a particular register
number without risking erroring out if nothing is found.
The patch also adjusts the feature detection code for aarch64-fbsd, since
the infrastructure is shared amongst all aarch64 targets. I haven't added
code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if
that will happen.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them together
with FPCAR to identify if lazy FPU state preservation is active for
the current frame. See "Lazy context save of FP state", in B1.5.7,
also ARM AN298, supported by Cortex-M4F architecture for details on
lazy FPU register stacking. The same conditions are valid for other
Cortex-M cores with FPU.
This patch has been verified on a STM32F4-Discovery board by:
a) writing a non-zero value (lets use 0x1122334455667788 as an
example) to all the D-registers in the main function
b) configured the SysTick to fire
c) in the SysTick_Handler, write some other value (lets use
0x0022446688aaccee as an example) to one of the D-registers (D0 as
an example) and then do "SVC #0"
d) in the SVC_Handler, write some other value (lets use
0x0099aabbccddeeff) to one of the D-registers (D0 as an example)
In GDB, suspend the execution in the SVC_Handler function and compare
the value of the D-registers for the SVC_handler frame and the
SysTick_Handler frame. With the patch, the value of the modified
D-register (D0) should be the new value (0x009..eff) on the
SVC_Handler frame, and the intermediate value (0x002..cee) for the
SysTick_Handler frame. Now compare the D-register value for the
SysTick_Handler frame and the main frame. The main frame should
have the initial value (0x112..788).
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan ROUX <yvan.roux@foss.st.com>
This patch changes various global target_desc declarations to const, thereby
correcting a prominent source of ODR violations in PowerPC-related target code.
The majority of files/changes are mechanical const-ifications accomplished by
regenerating the C files in features/.
This also required manually updating mips-linux-tdep.h, s390-linux-tdep.h,
nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c,
and rs6000-tdep.c.
Patch tested against the sourceware trybot, and fully regression tested against
our (Red Hat's) internal test infrastructure on Rawhide aarch64, s390x, x86_64,
and powerpcle.
With this patch, I can finally enable LTO in our GDB package builds. [Tested
with a rawhide scratch build containing this patch.]
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24835
Add new files:
gdb/arch/csky.c
gdb/arch/csky.h
gdb/features/cskyv2-linux.c
gdbserver/linux-csky-low.cc
1. In gdb/arch/csky.c file, add function "csky_create_target_description()"
for csky_target::low_arch_setup(). later, it can be used for csky native gdb.
2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include
gprs, pc, hi, lo, float, vector and float control registers.
3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to
get/set registers. The main data structures in asm/ptrace.h are:
struct pt_regs {
unsigned long tls;
unsigned long lr;
unsigned long pc;
unsigned long sr;
unsigned long usp;
/*
* a0, a1, a2, a3:
* r0, r1, r2, r3
*/
unsigned long orig_a0;
unsigned long a0;
unsigned long a1;
unsigned long a2;
unsigned long a3;
/*
* r4 ~ r13
*/
unsigned long regs[10];
/* r16 ~ r30 */
unsigned long exregs[15];
unsigned long rhi;
unsigned long rlo;
unsigned long dcsr;
};
struct user_fp {
unsigned long vr[96];
unsigned long fcr;
unsigned long fesr;
unsigned long fid;
unsigned long reserved;
};
First, some background on the RISC-V registers fflags, frm, and fcsr.
These three registers all relate to the floating-point status and
control mechanism on RISC-V. The fcsr is the floatint-point control
status register, and consists of two parts, the flags (bits 0 to 4)
and the rounding-mode (bits 5 to 7).
The fcsr register is just one of many control/status registers (or
CSRs) available on RISC-V. The fflags and frm registers are also
CSRs. These CSRs are aliases for the relevant parts of the fcsr
register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is
an alias for bits 5 to 7 of fcsr.
This means that a user can change the floating-point rounding mode
either, by writing a complete new value into fcsr, or by writing just
the rounding mode into frm.
How this impacts on GDB is like this: a target description could,
legitimately include all three registers, fcsr, fflags, and frm. The
QEMU target currently does this, and this makes sense. The target is
emulating the complete system, and has all three CSRs available, so
why not tell GDB about this.
In contrast, the RISC-V native Linux target only has access to the
fcsr. This is because the ptrace data structure that the kernel uses
for reading and writing floating point state only contains a copy of
the fcsr, after all, this one field really contains both the fflags
and frm fields, so why carry around duplicate data.
So, we might expect that the target description for the RISC-V native
Linux GDB would only contain the fcsr register. Unfortunately, this
is not the case. The RISC-V native Linux target uses GDB's builtin
target descriptions by calling riscv_lookup_target_description, this
will then add an fpu feature from gdb/features/riscv, either
32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features
include an entry for fcsr, fflags, and frm. This means that GDB
expects the target to handle reading and writing these registers. And
the RISC-V native Linux target currently doesn't.
In riscv_linux_nat_target::store_registers and
riscv_linux_nat_target::fetch_registers only the fcsr register is
handled, this means that, for RISC-V native Linux, the fflags and frm
registers always show up as <unavailable> - they are present in the
target description, but the target doesn't know how to access the
registers.
A final complication relating to these floating pointer CSRs is which
target description feature the registers appear in.
These registers are CSRs, so it would seem sensible that these
registers should appear in the CSR target description feature.
However, when I first added RISC-V target description support, I was
using a RISC-V simulator that didn't support any CSRs other than the
floating point related ones. This simulator bundled all the float
related CSRs into the fpu target feature. This didn't feel completely
unreasonable to me, and so I had GDB check for these registers in
either target feature.
In this commit I make some changes relating to how GDB handles the
three floating point CSR:
1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This
means that the default RISC-V target description (which RISC-V native
FreeBSD), and the target descriptions created for RISC-V native Linux,
will not include these registers. There's nothing stopping some other
target (e.g. QEMU) from continuing to include all three of these CSRs,
the code in riscv-tdep.c continues to check for all three of these
registers, and will handle them correctly if they are present.
2. If a target supplied fcsr, but does not supply fflags and/or frm,
then RISC-V GDB will now create two pseudo registers in order to
emulate the two missing CSRs. These new pseudo-registers do the
obvious thing of just reading and writing the fcsr register.
3. With the new pseudo-registers we can no longer make use of the GDB
register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
These will be the numbers used if the target supplies the registers in
its target description, but, if GDB falls back to using
pseudo-registers, then new, unique numbers will be used. To handle
this I've added riscv_gdbarch_tdep::fflags_regnum and
riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
compare against these fields.
When adding the pseudo-register support, it is important that the
pseudo-register numbers are calculated after the call to
tdesc_use_registers. This is because we don't know the total number
of physical registers until after this call, and the psuedo-register
numbers must follow on from the real (target supplied) registers.
I've updated some tests to include more testing of the fflags and frm
registers, as well as adding a new test.
The current implementation of the fcc register is referenced to the
user_fp_state structure of the kernel uapi [1].
struct user_fp_state {
uint64_t fpr[32];
uint64_t fcc;
uint32_t fcsr;
};
But it is mistakenly defined as a 64-bit fputype register, resulting
in a confusing output of "info register".
(gdb) info register
...
fcc {f = 0x0, d = 0x0} {f = 0, d = 0}
...
According to "Condition Flag Register" in "LoongArch Reference Manual"
[2], there are 8 condition flag registers of size 1. Use 8 registers of
uint8 to make it easier for users to view the fcc register groups.
(gdb) info register
...
fcc0 0x1 1
fcc1 0x0 0
fcc2 0x0 0
fcc3 0x0 0
fcc4 0x0 0
fcc5 0x0 0
fcc6 0x0 0
fcc7 0x0 0
...
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h
[2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register
Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.
The format is documented in the Linux Kernel documentation [1].
Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.
To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.
When reading the data back, the tags are unpacked.
I've added a new testcase to exercise the feature.
Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.
[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
Move "enum loongarch_regnum" to gdb/arch/loongarch.h so that the
macro definitions can be used in gdbserver/linux-loongarch-low.cc
to simplify the code.
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
The FPCCR.TS bit is used to identify if FPU registers are considered
non-secure or secure. If they are secure, then callee saved registers
(S16 to S31) are stacked on exception entry or otherwise skipped.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Signed-off-by: Yvan Roux <yvan.roux@foss.st.com>
Implement LoongArch/Linux support, including XML target description
handling based on features determined, GPR regset support, and software
breakpoint handling.
In the Linux kernel code of LoongArch, ptrace implements PTRACE_POKEUSR
and PTRACE_PEEKUSR in the arch_ptrace function, so srv_linux_usrregs is
set to yes.
With this patch on LoongArch:
$ make check-gdb TESTS="gdb.server/server-connect.exp"
[...]
# of expected passes 18
[...]
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Move the specialization into an explicit std namespace to workaround a
bug in older compilers. GCC 6.4.1 at least fails to compile the previous
version with the following error:
gdb/arch/aarch64.h:48:13: error: specialization of 'template<class _Tp> struct std::hash' in different namespace [-fpermissive]
struct std::hash<aarch64_features>
Replace the sve bool member of aarch64_features with a vq member that
holds the vector quotient. It is zero if SVE is not present.
Add std::hash<> specialization and operator== so that aarch64_features
can be used as a key with std::unordered_map<>.
Change the various functions that create or lookup aarch64 target
descriptions to accept a const aarch64_features object rather than a
growing number of arguments.
Replace the multi-dimension tdesc_aarch64_list arrays used to cache
target descriptions with unordered_maps indexed by aarch64_feature.
This patch removes the hardcoded access to PSP in
arm_m_exception_cache() and relies on the definition with the XML
descriptions.
Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com>
Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
This set of changes enable support for the ARMv8.1-m PACBTI extensions [1].
The goal of the PACBTI extensions is similar in scope to that of a-profile
PAC/BTI (aarch64 only), but the underlying implementation is different.
One important difference is that the pointer authentication code is stored
in a separate register, thus we don't need to mask/unmask the return address
from a function in order to produce a correct backtrace.
The patch introduces the following modifications:
- Extend the prologue analyser for 32-bit ARM to handle some instructions
from ARMv8.1-m PACBTI: pac, aut, pacg, autg and bti. Also keep track of
return address signing/authentication instructions.
- Adds code to identify object file attributes that indicate the presence of
ARMv8.1-m PACBTI (Tag_PAC_extension, Tag_BTI_extension, Tag_PACRET_use and
Tag_BTI_use).
- Adds support for DWARF pseudo-register RA_AUTH_CODE, as described in the
aadwarf32 [2].
- Extends the dwarf unwinder to track the value of RA_AUTH_CODE.
- Decorates backtraces with the "[PAC]" identifier when a frame has signed
the return address.
- Makes GDB aware of a new XML feature "org.gnu.gdb.arm.m-profile-pacbti". This
feature is not included as an XML file on GDB's side because it is only
supported for bare metal targets.
- Additional documentation.
[1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-1-m-pointer-authentication-and-branch-target-identification-extension
[2] https://github.com/ARM-software/abi-aa/blob/main/aadwarf32/aadwarf32.rst
1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate
them into a single keys.xml.
2. Enable PKU for x32 to fix:
$ gdbserver :123456 x32-program
...
.../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected
.
Unknown register pkru requested
on Tiger Lake.
This commit adds initial target description support for LoongArch.
Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn>
Signed-off-by: Qing zhang <zhangqing@loongson.cn>
Signed-off-by: Youling Tang <tangyouling@loongson.cn>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Change gdb_assert_not_reached to accept a format string plus
corresponding arguments. This allows giving more precise messages.
Because the format string passed by the caller is prepended with a "%s:"
to add the function name, the callers can no longer pass a translated
string (`_(...)`). Make the gdb_assert_not_reached include the _(),
just like the gdb_assert_fail macro just above.
Change-Id: Id0cfda5a57979df6cdaacaba0d55dd91ae9efee7
The current register set selection mechanism for AArch64 is static, based
on a pre-populated array of register sets.
This means that we might potentially probe register sets that are not
available. This is OK if the kernel errors out during ptrace, but probing the
tag_ctl register, for example, does not result in a ptrace error if the kernel
supports the tagged address ABI but not MTE (PR 28355).
Making the register set selection dynamic, based on feature checks, solves
this and simplifies the code a bit. It allows us to list all of the register
sets only once, and pick and choose based on HWCAP/HWCAP2 or other properties.
I plan to backport this fix to GDB 11 as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28355
In preparation for the MVE extension patch, this one refactors some of
the register-related constants we have for ARM.
Basically I'm separating counting constants from numbering constants.
For example, ARM_A1_REGNUM is a numbering constant, whereas ARM_NUM_ARG_REGS
is a counting constant.
This commit adds support to RISC-V GDB for vector registers in the
incoming target description.
The vector registers should be described in a feature called
"org.gnu.gdb.riscv.vector", and should contain the register v0 to
v31. There's no restriction on the size or type of these registers,
so the target description can set these up as it requires.
However, if the target feature is present then all of the registers
must be present, and they must all be the same size, these
requirements are, I believe, inline with the RISC-V vector extension.
The DWARF register numbers for the vector registers have been added,
and the code to map between GDB's internal numbering and the DWARF
numbering has been updated.
I have not yet added a feature/riscv/*.xml file for the vector
extension, the consequence of this is that we can't, right now, detect
vector registers on a native target, this patch is all about
supporting vectors on a remote target.
It is worth noting that I don't actually have access to a RISC-V
target with vectors, so the only testing that this patch has had has
been done using 'set tdesc filename ....' to load a target description
to which I have manually added the vector feature. This has shown
that the vector register feature can be successfully parsed, and that
the registers show up in the expected register groups.
Additionally, the RISC-V vector extension is currently at v0.10, which
is also the v1.0 draft release. However, this extension is not yet
finalised. It is possible (but unlikely I think) that the register
set could change between now and the final release of the vector
extension. If this were to happen then we would potentially end up
changing the requirements for the new org.gnu.gdb.riscv.vector
feature. I really don't think it is likely that the register set will
change this late in the process, and even if it did, changing the
feature requirements will not be a problem as far as I am
concerned (when the alternative is GDB just continues without this
feature for now).
gdb/ChangeLog:
* NEWS: Mention new target feature name.
* arch/riscv.c (riscv_create_target_description): GDB doesn't
currently create target descriptions containing vector registers.
* arch/riscv.h (struct riscv_gdbarch_features) <vlen>: New member
variable.
<operator==>: Also compare vlen.
<hash>: Also include vlen.
* riscv-tdep.c (riscv_feature_name_vector): New static global.
(struct riscv_vector_feature): New struct.
(riscv_vector_feature): New static global.
(riscv_register_reggroup_p): Ensure vector registers are part of
the 'all' group, and part of the 'vector' group.
(riscv_dwarf_reg_to_regnum): Handle vector registers.
(riscv_gdbarch_init): Check vector register feature.
* riscv-tdep.h: Add vector registers to GDB's internal register
numbers, and to the DWARF register numbers.
gdb/doc/ChangeLog:
* gdb.texinfo (RISC-V Features): Mention vector register feature.
When we want to fetch tags from a memory range, the last address in that
range is not included.
There is a off-by-one error in aarch64_mte_get_tag_granules, which this
patch fixes.
gdb/ChangeLog:
2021-05-13 Luis Machado <luis.machado@linaro.org>
* arch/aarch64-mte-linux.c (aarch64_mte_get_tag_granules): Don't
include the last address in the range.
Whenever a memory tag violation occurs, we get a SIGSEGV. Additional
information can be obtained through the siginfo data structure.
For AArch64 the Linux kernel may expose the fault address and tag
information, if we have a synchronous event. Otherwise there is
no fault address available.
The synchronous event looks like this:
--
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault
Memory tag violation while accessing address 0x0500fffff7ff8000
Allocation tag 0x1.
Logical tag 0x5
--
The asynchronous event looks like this:
--
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault
Memory tag violation
Fault address unavailable.
--
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c
(aarch64_linux_report_signal_info): New function.
(aarch64_linux_init_abi): Register
aarch64_linux_report_signal_info as the report_signal_info hook.
* arch/aarch64-linux.h (SEGV_MTEAERR): Define.
(SEGV_MTESERR): Define.
The patch implements the memory tagging target hooks for AArch64, so we
can handle MTE.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (ALL_64_TARGET_OBS): Add arch/aarch64-mte-linux.o.
(HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h and
nat/aarch64-mte-linux-ptrace.h.
* aarch64-linux-nat.c: Include nat/aarch64-mte-linux-ptrace.h.
(aarch64_linux_nat_target) <supports_memory_tagging>: New method
override.
<fetch_memtags>: New method override.
<store_memtags>: New method override.
(aarch64_linux_nat_target::supports_memory_tagging): New method.
(aarch64_linux_nat_target::fetch_memtags): New method.
(aarch64_linux_nat_target::store_memtags): New method.
* arch/aarch64-mte-linux.c: New file.
* arch/aarch64-mte-linux.h: Include gdbsupport/common-defs.h.
(AARCH64_MTE_GRANULE_SIZE): Define.
(aarch64_memtag_type): New enum.
(aarch64_mte_get_tag_granules): New prototype.
* configure.nat (NATDEPFILES): Add nat/aarch64-mte-linux-ptrace.o.
* configure.tgt (aarch64*-*-linux*): Add arch/aarch64-mte-linux.o.
* nat/aarch64-mte-linux-ptrace.c: New file.
* nat/aarch64-mte-linux-ptrace.h: New file.
AArch64 MTE support in the Linux kernel exposes a new register
through ptrace. This patch adds the required code to support it.
include/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* elf/common.h (NT_ARM_TAGGED_ADDR_CTRL): Define.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c (fetch_mteregs_from_thread): New function.
(store_mteregs_to_thread): New function.
(aarch64_linux_nat_target::fetch_registers): Update to call
fetch_mteregs_from_thread.
(aarch64_linux_nat_target::store_registers): Update to call
store_mteregs_to_thread.
* aarch64-tdep.c (aarch64_mte_register_names): New struct.
(aarch64_cannot_store_register): Handle MTE registers.
(aarch64_gdbarch_init): Initialize and setup MTE registers.
* aarch64-tdep.h (gdbarch_tdep) <mte_reg_base>: New field.
<has_mte>: New method.
* arch/aarch64-linux.h (AARCH64_LINUX_SIZEOF_MTE): Define.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc (aarch64_fill_mteregset): New function.
(aarch64_store_mteregset): New function.
(aarch64_regsets): Add MTE register set entry.
(aarch64_sve_regsets): Add MTE register set entry.
This patch adds a target description and feature "mte" for aarch64.
It includes one new register, tag_ctl, that can be used to configure the
tag generation rules and sync/async modes. It is 64-bit in size.
The patch also adjusts the code that creates the target descriptions at
runtime based on CPU feature checks.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-nat.c
(aarch64_linux_nat_target::read_description): Take MTE flag into
account.
Slight refactor to hwcap flag checking.
* aarch64-linux-tdep.c
(aarch64_linux_core_read_description): Likewise.
* aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for
MTE.
(aarch64_read_description): Add mte_p parameter and update to use it.
Update the documentation.
(aarch64_gdbarch_init): Update call to aarch64_read_description.
* aarch64-tdep.h (aarch64_read_description): Add mte_p parameter.
* arch/aarch64.c: Include ../features/aarch64-mte.c.
(aarch64_create_target_description): Add mte_p parameter and update
the code to use it.
* arch/aarch64.h (aarch64_create_target_description): Add mte_p
parameter.
* features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml.
* features/aarch64-mte.c: New file, generated.
* features/aarch64-mte.xml: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to
aarch64_linux_read_description.
(initialize_low_tracepoint): Likewise.
* linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag
into account.
* linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension
for MTE.
(aarch64_linux_read_description): Add mte_p parameter and update to
use it.
* linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p
parameter.
This patch is a preparation for the next patches implementing MTE. It just adds
a HWCAP2 constant for MTE, creates a new generic arch/aarch64-mte-linux.h file
and includes that file in the source files that will use it.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* Makefile.in (HFILES_NO_SRCDIR): Add arch/aarch64-mte-linux.h.
* aarch64-linux-nat.c: Include arch/aarch64-mte-linux.h.
* aarch64-linux-tdep.c: Likewise
* arch/aarch64-mte-linux.h: New file.
gdbserver/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* linux-aarch64-low.cc: Include arch/aarch64-mte-linux.h.
Enable displaced stepping over a BR/BLR instruction
Displaced stepping over an instruction executes a instruction in a
scratch area and then manually fixes up the PC address to leave
execution where it would have been if the instruction were in its
original location.
The BR instruction does not need modification in order to run correctly
at a different address, but the displaced step fixup method should not
manually adjust the PC since the BR instruction sets that value already.
The BLR instruction should also avoid such a fixup, but must also have
the link register modified to point to just after the original code
location rather than back to the scratch location.
This patch adds the above functionality.
We add this functionality by modifying aarch64_displaced_step_others
rather than by adding a new visitor method to aarch64_insn_visitor.
We choose this since it seems that visitor approach is designed
specifically for PC relative instructions (which must always be modified
when executed in a different location).
It seems that the BR and BLR instructions are more like the RET
instruction which is already handled specially in
aarch64_displaced_step_others.
This also means the gdbserver code to relocate an instruction when
creating a fast tracepoint does not need to be modified, since nothing
special is needed for the BR and BLR instructions there.
Regression tests showed nothing untoward on native aarch64 (though it
took a while for me to get the testcase to account for PIE).
------#####
Original observed (mis)behaviour before was that displaced stepping over
a BR or BLR instruction would not execute the function they called.
Most easily seen by putting a breakpoint with a condition on such an
instruction and a print statement in the functions they called.
When run with the breakpoint enabled the function is not called and
"numargs called" is not printed.
When run with the breakpoint disabled the function is called and the
message is printed.
--- GDB Session
~ [15:57:14] % gdb ../using-blr
Reading symbols from ../using-blr...done.
(gdb) disassemble blr_call_value
Dump of assembler code for function blr_call_value:
...
0x0000000000400560 <+28>: blr x2
...
0x00000000004005b8 <+116>: ret
End of assembler dump.
(gdb) break *0x0000000000400560
Breakpoint 1 at 0x400560: file ../using-blr.c, line 22.
(gdb) condition 1 10 == 0
(gdb) run
Starting program: /home/matmal01/using-blr
[Inferior 1 (process 33279) exited with code 012]
(gdb) disable 1
(gdb) run
Starting program: /home/matmal01/using-blr
numargs called
[Inferior 1 (process 33289) exited with code 012]
(gdb)
Test program:
---- using-blr ----
\#include <stdio.h>
typedef int (foo) (int, int);
typedef void (bar) (int, int);
struct sls_testclass {
foo *x;
bar *y;
int left;
int right;
};
__attribute__ ((noinline))
int blr_call_value (struct sls_testclass x)
{
int retval = x.x(x.left, x.right);
if (retval % 10)
return 100;
return 9;
}
__attribute__ ((noinline))
int blr_call (struct sls_testclass x)
{
x.y(x.left, x.right);
if (x.left % 10)
return 100;
return 9;
}
int
numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("numargs called\n");
return 10;
}
void
altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right)
{
printf("altfunc called\n");
}
int main(int argc, char **argv)
{
struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 };
if (argc > 2)
{
blr_call (x);
}
else
blr_call_value (x);
return 10;
}
I haven't tried this on an actual aarch64 machine, but I am able to
exercise it like this:
(gdb) set debug aarch64
(gdb) maintenance selftest aa
Running selftest aarch64-analyze-prologue.
[aarch64] aarch64_analyze_prologue: prologue analysis gave up addr=0x14 opcode=0xf94013e0
Running selftest aarch64-process-record.
Ran 2 unit tests, 0 failed
gdb/ChangeLog:
* arch/aarch64-insn.h (aarch64_debug_printf): New.
* arch/aarch64-insn.c: Use aarch64_debug_printf.
* aarch64-tdep.c: Use aarch64_debug_printf.
Change-Id: Ifdb40e2816ab8e55a9aabb066d1833d9b5a46094
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
The FPSIMD dump in signal frames and ptrace FPSIMD dump in the SVE context
structure follows the target endianness, whereas the SVE dumps are
endianness-independent (LE).
Therefore, when the system is in BE mode, we need to reverse the bytes
for the FPSIMD data.
Given the V registers are larger than 64-bit, I've added a way for value
bytes to be set, as opposed to passing a 64-bit fixed quantity. This fits
nicely with the unwinding *_got_bytes function and makes the trad-frame
more flexible and capable of saving larger registers.
The memory for the bytes is allocated via the frame obstack, so it gets freed
after we're done inspecting the frame.
gdb/ChangeLog:
2020-12-10 Luis Machado <luis.machado@linaro.org>
* aarch64-linux-tdep.c (aarch64_linux_restore_vreg) New function.
(aarch64_linux_sigframe_init): Call aarch64_linux_restore_vreg.
* aarch64-tdep.h (V_REGISTER_SIZE): Move to ...
* arch/aarch64.h: ... here.
* nat/aarch64-sve-linux-ptrace.c: Include endian.h.
(aarch64_maybe_swab128): New function.
(aarch64_sve_regs_copy_to_reg_buf)
(aarch64_sve_regs_copy_from_reg_buf): Adjust FPSIMD entries.
* trad-frame.c (trad_frame_reset_saved_regs): Initialize
the data field.
(TF_REG_VALUE_BYTES): New enum value.
(trad_frame_value_bytes_p): New function.
(trad_frame_set_value_bytes): New function.
(trad_frame_set_reg_value_bytes): New function.
(trad_frame_get_prev_register): Handle register values saved as bytes.
* trad-frame.h (trad_frame_set_reg_value_bytes): New prototype.
(struct trad_frame_saved_reg) <data>: New field.
(trad_frame_set_value_bytes): New prototype.
(trad_frame_value_bytes_p): New prototype.
