aboutsummaryrefslogtreecommitdiff
path: root/gdb/arch
AgeCommit message (Collapse)AuthorFilesLines
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi16-16/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-03-26Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32"Andrew Burgess1-6/+2
This reverts commit efba976d9713a92b4507ccfef2257e4589da2798.
2024-03-25gdb/arch: assert that X86_XSTATE_MPX is not set for x32Andrew Burgess1-2/+6
While trying to merge this commit: commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a Date: Wed Mar 20 04:13:18 2024 -0700 gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 With this patch series of mine: https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com I worried that there could be other paths that could result in an xcr0 value that has X86_XSTATE_MPX set in x32 mode. As everyone eventually calls amd64_create_target_description to build their target description, I figured we could assert in here that if X86_XSTATE_MPX is set then we should not be an x32 target, this should uncover any other bugs in this area. I'm not currently able to build/run any x32 binaries, so I have no way to test this. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511
2024-03-02gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35Hui Li1-1/+2
There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())" in find_register_by_number() when gdb connects to gdbserver, this is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains 10 reserved regs) is different with the number of regs (35, which not contains 10 reserved regs) in file gdb/features/loongarch/base64.xml. Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to keep consistent with the gdb/features/loongarch/base64.xml, and then define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that all the reg numbers in regcache are consistent with tdesc reg numbers. without this patch: Execute on the target machine: $ gdbserver 192.168.1.123:5678 ./test Execute on the host machine: $ gdb ./test (gdb) target remote 192.168.1.123:5678 Output on the target machine: Process ./test created; pid = 67683 Listening on port 5678 Remote debugging from host 192.168.1.136, port 6789 gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected. find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed. Output on the host machine: Remote debugging using 192.168.1.123:5678 Remote connection closed Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: John Baldwin <jhb@FreeBSD.org> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-02-29gdb/arm: Remove tpidruro register from non-FreeBSD target descriptionsThiago Jung Bauermann2-3/+4
Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which adds the tpidruro register, and unconditionally enabled it in aarch32_create_target_description. In Linux, the tpidruro register isn't available via ptrace in the 32-bit kernel but it is available for an aarch32 program running under an arm64 kernel via the ptrace compat interface. This isn't currently implemented however, which causes GDB on arm-linux with 64-bit kernel to list the register but show it as unavailable, as reported by Tom de Vries: $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' Temporary breakpoint 1 at 0x512 Temporary breakpoint 1, 0xaaaaa512 in main () $1 = <unavailable> Simon Marchi then clarified: > The only time we should be seeing some "unavailable" registers or memory > is in the context of tracepoints, for things that are not collected. > Seeing an unavailable register here is a sign that something is not > right. Therefore, disable the TLS feature in aarch32 target descriptions for Linux and NetBSD targets (the latter also doesn't seem to support accessing tpidruro either, based on a quick look at arm-netbsd-nat.c). This patch fixes the following tests: Running gdb.base/inline-frame-cycle-unwind.exp ... FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3 FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native, native-gdbserver and native-extended-gdbserver targets with no regressions. PR tdep/31418 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-02-28aarch64: Use aarch64_debug_printf in a few more placesJohn Baldwin1-32/+19
No functional change Approved-By: Simon Marchi <simon.marchi@efficios.com>
2024-02-06gdb: LoongArch: Add LBT extension supportFeiyang Chen2-0/+12
Loongson Binary Translation (LBT) is used to accelerate binary translation, which contains 4 scratch registers (scr0 to scr3), x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This patch support gdb to fetch/store these registers. Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> # Framework Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-02-06gdb: LoongArch: Add vector extensions supportHui Li2-0/+10
Add LoongArch's vector extensions support, which including 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX (i.e., Loongson Advanced SIMD eXtension). This patch support gdb to fetch/store vector registers. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess34-34/+34
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-12-14gdb: use reg_buffer_common throughout gdbsupport/common-regcache.hSimon Marchi4-9/+10
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>
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-1/+1
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>
2023-10-04sme2: Enable SME2 for AArch64 gdb on LinuxLuis Machado3-1/+21
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>
2023-10-04sme: Core file support for LinuxLuis Machado2-0/+49
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>
2023-10-04sme: Enable SME registers and pseudo-registersLuis Machado4-4/+117
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>
2023-08-11RISC-V: Reflect actual range of vlen for hashingTsukasa OI1-1/+1
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.
2023-08-11RISC-V: Add reference to Zve32*Tsukasa OI1-3/+4
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*').
2023-02-21[aarch64] Enable pointer authentication support for aarch64 bare ↵Luis Machado1-0/+6
metal/kernel mode addresses 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
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker32-32/+32
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.
2022-12-16[aarch64] Fix removal of non-address bits for PAuthLuis Machado2-0/+49
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>
2022-12-09[aarch64] Add TPIDR2 register support for LinuxLuis Machado2-7/+12
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.
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-1/+1
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
2022-10-06gdb/arm: Handle lazy FPU state preservationTorbjörn SVENSSON1-1/+6
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>
2022-09-29Constify target_desc declarationsKeith Seitz2-21/+21
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
2022-09-23gdb/csky add cskyv2-linux.xml for cskyv2-linux.cJiangshuai Li1-1/+1
Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed. Also update cskyv2-linux.c.
2022-09-13gdbserver/csky add csky gdbserver supportJiangshuai Li2-0/+67
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; };
2022-08-31gdb/riscv: better support for fflags and frm registersAndrew Burgess1-2/+17
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.
2022-08-09gdb/gdbserver: LoongArch: Improve implementation of fcc registersFeiyang Chen1-3/+4
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>
2022-07-19[AArch64] MTE corefile supportLuis Machado2-0/+66
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)
2022-07-12gdb: LoongArch: Add floating-point supportTiezhu Yang2-1/+25
This commit adds floating-point support for LoongArch gdb. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-10Fix include guard naming for arch/aarch64-mte-linux.hLuis Machado1-3/+3
It should be ARCH_AARCH64_MTE_LINUX_H as opposed to ARCH_AARCH64_LINUX_H.
2022-07-10gdbserver: LoongArch: Simplify code with register number macrosYouling Tang1-0/+16
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>
2022-06-29gdb/arm: Only stack S16..S31 when FPU registers are secureYvan Roux1-0/+9
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>
2022-06-14gdbserver: Add LoongArch/Linux supportYouling Tang2-1/+24
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>
2022-05-23Tweak the std::hash<> specialization for aarch64_features.John Baldwin1-12/+15
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>
2022-05-18Use aarch64_features to describe register features in target descriptions.John Baldwin2-17/+36
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.
2022-05-03Add an aarch64-tls feature which includes the tpidr register.John Baldwin2-3/+12
2022-05-03Add an arm-tls feature which includes the tpidruro register from CP15.John Baldwin3-2/+8
2022-04-27gdb/arm: Define MSP and PSP registers for M-ProfileChristophe Lyon2-0/+7
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>
2022-04-06Enable ARMv8.1-m PACBTI supportLuis Machado1-0/+13
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
2022-03-31gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xmlH.J. Lu2-5/+5
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.
2022-02-11gdb: LoongArch: Add initial target description supportTiezhu Yang2-0/+161
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>
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker28-28/+28
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.
2021-11-18gdbsupport: make gdb_assert_not_reached accept a format stringSimon Marchi1-2/+2
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
2021-11-15Extend the prologue analyzer to handle the bti instructionLuis Machado1-0/+5
Handle the BTI instruction in the prologue analyzer. The patch handles all the variations of the BTI instruction.
2021-11-03[AArch64] Make gdbserver register set selection dynamicLuis Machado1-0/+9
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
2021-10-11[ARM] Add support for M-profile MVE extensionSrinath Parvathaneni2-0/+10
This patch adds support for the M-profile MVE extension, which includes the following: - New M-profile XML feature m-profile-mve - MVE vector predication status and control register (VPR) - p0 pseudo register (contained in the VPR) - q0 ~ q7 pseudo vector registers - New feature bits - Documentation update Pseudo register p0 is the least significant bits of vpr and can be accessed as $p0 or displayed through $vpr. For more information about the register layout, please refer to [1]. The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers per q register. The register dump looks like this: (gdb) info reg all r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x0 0x0 <__Vectors> lr 0xffffffff -1 pc 0xd0c 0xd0c <Reset_Handler> xpsr 0x1000000 16777216 d0 0 (raw 0x0000000000000000) d1 0 (raw 0x0000000000000000) d2 0 (raw 0x0000000000000000) d3 0 (raw 0x0000000000000000) d4 0 (raw 0x0000000000000000) d5 0 (raw 0x0000000000000000) d6 0 (raw 0x0000000000000000) d7 0 (raw 0x0000000000000000) d8 0 (raw 0x0000000000000000) d9 0 (raw 0x0000000000000000) d10 0 (raw 0x0000000000000000) d11 0 (raw 0x0000000000000000) d12 0 (raw 0x0000000000000000) d13 0 (raw 0x0000000000000000) d14 0 (raw 0x0000000000000000) d15 0 (raw 0x0000000000000000) fpscr 0x0 0 vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ] s0 0 (raw 0x00000000) s1 0 (raw 0x00000000) s2 0 (raw 0x00000000) s3 0 (raw 0x00000000) s4 0 (raw 0x00000000) s5 0 (raw 0x00000000) s6 0 (raw 0x00000000) s7 0 (raw 0x00000000) s8 0 (raw 0x00000000) s9 0 (raw 0x00000000) s10 0 (raw 0x00000000) s11 0 (raw 0x00000000) s12 0 (raw 0x00000000) s13 0 (raw 0x00000000) s14 0 (raw 0x00000000) s15 0 (raw 0x00000000) s16 0 (raw 0x00000000) s17 0 (raw 0x00000000) s18 0 (raw 0x00000000) s19 0 (raw 0x00000000) s20 0 (raw 0x00000000) s21 0 (raw 0x00000000) s22 0 (raw 0x00000000) s23 0 (raw 0x00000000) s24 0 (raw 0x00000000) s25 0 (raw 0x00000000) s26 0 (raw 0x00000000) s27 0 (raw 0x00000000) s28 0 (raw 0x00000000) s29 0 (raw 0x00000000) s30 0 (raw 0x00000000) s31 0 (raw 0x00000000) q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} p0 0x0 0 Built and regtested with a simulator. [1] https://developer.arm.com/documentation/ddi0553/bn Co-Authored-By: Luis Machado <luis.machado@linaro.org>
2021-10-11[ARM] Refactor some constantsLuis Machado1-4/+10
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.
2021-06-21gdb/riscv: add support for vector registers in target descriptionsAndrew Burgess2-2/+16
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.
2021-05-13[AArch64] Fix off-by-one when calculating tag granules.Luis Machado1-2/+3
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.
2021-03-24AArch64: Report tag violation error informationLuis Machado1-0/+6
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.
generated by cgit v1.1 at 2024-11-24 06:06:59 +0000