aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-11-09x86: Intel Core processors do not support CMPXCHG16BJan Beulich2-2/+2
This being a 64-bit-only instruction (see also i386-opc.tbl) it cannot possibly be supported by CPUs not supporting 64-bit mode.
2023-11-09Automatic date update in version.inGDB Administrator1-1/+1
2023-11-08rs6000, Fix test gdb.base/store.expCarl Love2-1/+68
The test currently fails for IEEE 128-bit floating point types. PowerPC supports the IBM double 128-bit floating point format and IEEE 128-bit format. The IBM double 128-bit floating point format uses two 64-bit floating point registers to store the 128-bit value. The IEEE 128-bit floating point format stores the value in a single 128-bit vector-scalar register (vsr). The various floating point values, 32-bit float, 64-bit double, IBM double 128-bit float and IEEE 128-bit floating point numbers are all mapped to the DWARF fpr numbers. The issue is the IEEE 128-bit floating point values are actually stored in a vsr not the fprs. This patch changes the register mapping for the vsrs from the fpr to the vsr registers so the value is properly accessed by GDB. The functions rs6000_linux_register_to_value, rs6000_linux_value_to_register, rs6000_linux_value_from_register check if the value is an IEEE 128-bit floating point value and adjust the register number as needed. The test in function rs6000_convert_register_p is fixed so it is only true for floating point values. This patch fixes three regression tests in gdb.base/store.exp. The patch has been tested on Power 8 LE/BE, Power 9 LE/BE and Power 10 LE with no regressions.
2023-11-08rs6000, Fix Linux DWARF register mappingCarl Love2-0/+66
Overview of issues fixed by the patch. The primary issue this patch fixes is the DWARF register mapping for Linux. The changes in ppc-linux-tdep.c fix the DWARF register mapping issues. The register mapping issue is responsible for two of the five regression bugs seen in gdb.base/store.exp. Once the register mapping was fixed, an underlying issue with the unwinding of the signal trampoline in common-code in ifrun.c was found. This underlying bug is best described by Ulrich in the following description. The unwinder bug shows up on platforms where the kernel uses a trampoline to dispatch "calls to" the signal handler (not just *returns from* the signal handler). Many platforms use a trampoline for signal return, and that is working fine, but the only platform I'm (Ulrich) aware of that uses a trampoline for signal handler calls is (recent kernels for) PowerPC. I believe the rationale for using a trampoline here is to improve performance by avoiding unbalancing of the branch predictor's call/return stack. However, on PowerPC the bug is dormant as well as it is hidden by *another* bug that prevents correct unwinding out of the signal trampoline. This is because the custom CFI for the trampoline uses a register number (VSCR) that is not ever used by compiler-generated CFI, and that particular register is mapped to an invalid number by the current PowerPC DWARF mapper. The underlying unwinder bug is exposed by the "new" regression failures in gdb.base/sigstep.exp. These failures were previously masked by the fact that GDB was not seeing a valid frame when it tried to unwind the frames. The sigstep.exp test is specifically testing stepping into a signal handler. With the correct DWARF register mapping in place, specifically the VSCR mapping, the signal trampoline code now unwinds to a valid frame exposing the pre-existing bug in how the signal handler on PowerPC works. The one line change infrun.c fixes the exiting bug in the common-code for platforms that use a trampoline to dispatch calls to the signal handler by not stopping in the SIGTRAMP_FRAME. Detailed description of the DWARF register mapping fix. The PowerPC DWARF register mapping is the same for the .eh_frame and .debug_frame on Linux. PowerPC uses different mapping for .eh_frame and .debug_frame on other operating systems. The current GDB support for mapping the DWARF registers in rs6000_linux_dwarf2_reg_to_regnum and rs6000_adjust_frame_regnum file gdb/rs6000-tdep.c is not correct for Linux. The files have some legacy mappings for spe_acc, spefscr, EV which was removed from GCC in 2017. This patch adds a two new functions rs6000_linux_dwarf2_reg_to_regnum, and rs6000_linux_adjust_frame_regnum in file gdb/ppc-linux-tdep.c to handle the DWARF register mappings on Linux. Function rs6000_linux_dwarf2_reg_to_regnum is installed for both gdb_dwarf_to_regnum and gdbarch_stab_reg_to_regnum since the mappings are the same. The ppc_linux_init_abi function in gdb/ppc-linux-tdep.c is updated to call set_gdbarch_dwarf2_reg_to_regnum map the new function rs6000_linux_dwarf2_reg_to_regnum for the architecture. Similarly, dwarf2_frame_set_adjust_regnum is called to map rs6000_linux_adjust_frame_regnum into the architecture. Additional detail on the signal handling fix. The specific sequence of events for handling a signal on most architectures is as follows: 1) Some code is running when a signal arrives. 2) The kernel handles the signal and dispatches to the handler. ... However on PowerPC the sequence of events is: 1) Some code is running when a signal arrives. 2) The kernel handles the signal and dispatches to the trampoline. 3) The trampoline performs a normal function call to the handler. ... We want the "nexti" to step into, not over, signal handlers invoked by the kernel. This is the case for most platforms as the kernel puts a signal trampoline frame onto the stack to handle proper return after the handler. However, on some platforms such as PowerPC, the kernel actually uses a trampoline to handle *invocation* of the handler. We do not want GDB to stop in the SIGTRAMP_FRAME. The issue is fixed in function process_event_stop_test by adding a check that the frame is not a SIGTRAMP_FRAME to the if statement to stop in a subroutine call. This prevents GDB from erroneously detecting the trampoline invocation as a subroutine call. This patch fixes two regression test failures in gdb.base/store.exp. The patch then fixes an exposed, dormant, signal handling issue that is exposed in the signal handling test gdb.base/sigstep.exp. The patch has been tested on Power 8 LE/BE, Power 9 LE/BE, Power 10 with no new regressions. Note, only two of the five failures in store.exp are fixed. The remaining three failures are fixed in a following patch.
2023-11-08gdb: call update_thread_list after completing an inferior callAndrew Burgess3-0/+270
I noticed that if GDB is using a remote or extended-remote target, then, if an inferior call caused a new thread to appear, or for an existing thread to exit, then these events are not reported to the user. The problem is that for these targets GDB relies on a call to update_thread_list to learn about changes to the inferior's thread list. If GDB doesn't pass through the normal stop code then GDB will not call update_thread_list, and so will not report changes in the thread list. This commit adds an additional update_thread_list call, after which thread events are correctly reported.
2023-11-08gdb: call update_thread_list for $_inferior_thread_count functionAndrew Burgess3-0/+257
I noticed that sometimes the value returned by $_inferior_thread_count can become out of sync with the actual thread count of the inferior, and will disagree with the number of threads reported by 'info threads'. This commit fixes this issue. The cause of the problem is that 'info threads' includes a call to update_thread_list, this can be seen in print_thread_info_1 in thread.c, while $_inferior_thread_count doesn't include a similar call, see the function inferior_thread_count_make_value also in thread.c. Of course, this is only a problem when GDB is running on a target that relies on update_thread_list calls to learn about new threads, e.g. remote or extended-remote targets. Native targets generally learn about new threads as soon as they appear and will not have this problem. I ran into this issue when writing a test for the next commit which uses inferior function calls to add an remove threads from an inferior. But for testing I've made use of non-stop mode and asynchronous inferior execution; by reading the inferior state I can know when a new thread has been created, at which point I can print $_inferior_thread_count while the inferior is still running. This is important, if I stop the inferior then GDB will pass through an update_thread_list call in the normal stop code, which will synchronise the thread list, after which $_inferior_thread_count will report the correct value. With this change in place $_inferior_thread_count is now correct.
2023-11-08gdb: add a custom command completer for disassemble commandAndrew Burgess3-1/+49
Add a new command completer function for the disassemble command. There are two things that this completion function changes. First, after the previous commit, the new function calls skip_over_slash_fmt, which means that hitting tab after entering a /OPT flag now inserts a space ready to start typing the address to disassemble at: (gdb) disassemble /r<TAB> (gdb) disassemble /r <CURSOR> But also, we now get symbol completion after a /OPT option set, previously this would do nothing: (gdb) disassemble /r mai<TAB> But now: (gdb) disassemble /r mai<TAB> (gdb) disassemble /r main <CURSOR> Which was my main motivation for working on this commit. However, I have made a second change in the completion function. Currently, the disassemble command calls the generic location_completer function, however, the disassemble docs say: Note that the 'disassemble' command's address arguments are specified using expressions in your programming language (*note Expressions: Expressions.), not location specs (*note Location Specifications::). So, for example, if you want to disassemble function 'bar' in file 'foo.c', you must type 'disassemble 'foo.c'::bar' and not 'disassemble foo.c:bar'. And indeed, if I try: (gdb) disassemble hello.c:main No symbol "hello" in current context. (gdb) disassemble hello.c::main No symbol "hello" in current context. (gdb) disassemble 'hello.c'::main Dump of assembler code for function main: ... snip ... But, if I do this: (gdb) disassemble hell<TAB> (gdb) disassemble hello.c:<CURSOR> which is a consequence of using the location_completer function. So in this commit, after calling skip_over_slash_fmt, I forward the bulk of the disassemble command completion to expression_completer. Now when I try this: (gdb) disassemble hell<TAB> gives nothing, which I think is an improvement. There is one slight disappointment, if I do: (gdb) disassemble 'hell<TAB> I still get nothing. I had hoped that this would expand to: 'hello.c':: but I guess this is a limitation of the current expression_completer implementation, however, I don't think this is a regression, the previous expansion was just wrong. Fixing expression_completer is out of scope for this commit. I've added some disassembler command completion tests, and also a test that disassembling using 'FILE'::FUNC syntax works, as I don't think that is tested anywhere.
2023-11-08gdb: make skip_over_slash_fmt available outside printcmd.cAndrew Burgess3-65/+70
Move the function skip_over_slash_fmt into completer.c, and make it extern, with a declaration in completer.h. This is a refactor in order to support the next commit. I've not changed any of the code in skip_over_slash_fmt. There should be no user visible changes after this commit.
2023-11-08gdb: error if /r and /b are used with disassemble commandAndrew Burgess5-6/+86
The disassembler gained a new /b flag in this commit: commit d4ce49b7ac077a9882d6a5e689e260300045ca88 Date: Tue Jun 21 20:23:35 2022 +0100 gdb: disassembler opcode display formatting The /b and /r flags result in the instruction opcodes displayed in different formats, so it's not possible to have both at the same time. Currently the /b flag overrides the /r flag. We have a similar situation with the /m and /s flags, but here, if the user tries to use both flags then they will get an error. I think the error is clearer, so in this commit I propose that we add an error if /r and /b are both used. Obviously this change breaks backwards compatibility. I don't have a compelling argument for why we should make the change beyond my feeling that it was a mistake not to add this error from the start, and that the new behaviour is better. Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-11-08gas: S_GET_{NAME,SEGMENT}() don't alter their input symbolJan Beulich2-4/+4
Make their parameters pointer-to-const, thus allowing callers to also be const-correct where possible.
2023-11-08ld: print branch fixups into the map file for ppc elf targetsClément Chigot2-3/+20
In a safety context, it could interesting to track the trampolines being generated, ensuring there are expected or not. bfd/ChangeLog: * elf32-ppc.c (ppc_elf_relax_section): Log branch fixups. ld/ChangeLog: * ld.texi (--print-map): Add new item about fixups.
2023-11-07Add minimal thread-safety to BFDTom Tromey7-55/+299
This patch provides some minimal thread-safety to BFD. The BFD client can request thread-safety by providing a lock and unlock function. The globals used during BFD creation (e.g., bfd_id_counter) are then locked, and the file descriptor cache is also locked. A function to clean up any thread-local data is now provided for BFD clients. * bfd-in2.h: Regenerate. * bfd.c (lock_fn, unlock_fn): New globals. (bfd_thread_init, bfd_thread_cleanup, bfd_lock, bfd_unlock): New functions. * cache.c (bfd_cache_lookup_worker): Use _bfd_open_file_unlocked. (cache_btell, cache_bseek, cache_bread, cache_bwrite): Lock and unlock. (cache_bclose): Add comment. (cache_bflush, cache_bstat, cache_bmmap): Lock and unlock. (_bfd_cache_init_unlocked): New function. (bfd_cache_init): Use it. Lock and unlock. (_bfd_cache_close_unlocked): New function. (bfd_cache_close, bfd_cache_close_all): Use it. Lock and unlock. (_bfd_open_file_unlocked): New function. (bfd_open_file): Use it. Lock and unlock. * doc/bfd.texi (BFD front end): Add Threading menu item. * libbfd.h: Regenerate. * opncls.c (_bfd_new_bfd): Lock and unlock. * po/bfd.pot: Regenerate.
2023-11-07Make various error-related globals thread-localTom Tromey8-36/+166
This changes bfd_error et al to be thread-local. * Makefile.in: Regenerate. * aclocal.m4: Include ax_tls.m4. * ax_tls.m4: New file. * bfd.c: (bfd_error, input_error, input_bfd, _bfd_error_buf): Now thread-local. (bfd_asprintf): Update docs. * config.in, configure: Regenerate. * configure.ac: Call AX_TLS. * po/bfd.pot: Regenerate.
2023-11-07Make _bfd_error_buf staticTom Tromey4-1197/+1364
This makes _bfd_error_buf static and adds a way to clear it. I felt that this made the subsequent patches a little cleaner. * bfd.c (_bfd_error_buf): Now static. (bfd_set_input_error): Use _bfd_clear_error_data. (_bfd_clear_error_data): New function. (bfd_init): Use _bfd_clear_error_data. * libbfd.h: Regenerate. * opncls.c (bfd_close_all_done): Use _bfd_clear_error_data. * po/bfd.pot: Regenerate.
2023-11-08Automatic date update in version.inGDB Administrator1-1/+1
2023-11-07aarch64: Add LSE128 instructionsVictor Do Nascimento7-2407/+2625
Implement, together with the necessary tests, the following new LSE128 atomic instructions: * Atomic bit clear on quadword in memory (ldclrp{a|l|al}); * Atomic bit set on quadword in memory (ldsetp{a|l|al}); * Swap quadword in memory (swpp{a|l|al}); gas/ChangeLog: * testsuite/gas/aarch64/lse128-atomic.d: New. * testsuite/gas/aarch64/lse128-atomic.s: Likewise. opcodes/ChangeLog: * aarch64-tbl.h (ldclrp): new _LSE128_INSN entry. (ldclrpa): Likewise. (ldclrpal): Likewise. (ldclrpl): Likewise. (ldsetp): Likewise. (ldsetpa): Likewise. (ldsetpal): Likewise. (ldsetpl): Likewise. (swpp): Likewise. (swppa): Likewise. (swppal): Likewise. (swppl): Likewise. * aarch64-asm-2.c: Regenerate. * aarch64-dis-2.c: Likewise. * aarch64-opc-2.c: Likewise.
2023-11-07aarch64: Add arch support for LSE128 extensionVictor Do Nascimento4-0/+11
Enable the `+lse128' feature modifier which, together with new internal feature flags, enables LSE128 instructions, which are represented via the new `_LSE128_INSN' macro. gas/ChangeLog: * config/tc-aarch64.c (aarch64_features): Add new "lse128" entry. include/ChangeLog: * include/opcode/aarch64.h (enum aarch64_feature_bit): New AARCH64_FEATURE_LSE128 feature bit. (enum aarch64_insn_class): New lse128_atomic instruction class. opcodes/ChangeLog: * opcodes/aarch64-tbl.h (aarch64_feature_lse128): New. (LSE128): Likewise. (_LSE128_INSN): Likewise.
2023-11-07aarch64: Add LSE128 instruction operand supportVictor Do Nascimento5-0/+15
Given the particular encoding of the LSE128 instructions, create the necessary shared input+output operand register description and handling in the code to allow for the encoding of the LSE128 128-bit atomic operations. gas/ChangeLog: * config/tc-aarch64.c (parse_operands): include/ChangeLog: * opcode/aarch64.h (enum aarch64_opnd): opcodes/ChangeLog: * aarch64-opc.c (fields): (aarch64_print_operand): * aarch64-opc.h (enum aarch64_field_kind): * aarch64-tbl.h (AARCH64_OPERANDS):
2023-11-07aarch64: Add 128-bit system register flagsVictor Do Nascimento2-10/+13
In preparation for the implementation of 128-bit system register support across the toolchain, this patch adds the feature flag F_REG_128 and adds it to relevant system registers in `aarch64-sys-regs.def'. Given the shared nature of this file, this change is made necessary initially to implement argument validation in the `__arm_rsr128' and `__armwsr128' ACLE intrinsics in GCC, but will be of subsequent use in the binutils implementation of the corresponding `mrrs' and `msrr' instructions. Regression tested on aarch64-linux-gnu, no regressions. opcodes/ChangeLog: * aarch64-opc.h (F_REG_128): New flag. * aarch64-sys-regs.def (par_el1): Add F_REG_128 flag. (rcwmask_el1): Likewise. (rcwsmask_el1): Likewise. (ttbr0_el1): Likewise. (ttbr0_el12): Likewise. (ttbr0_el2): Likewise. (ttbr1_el1): Likewise. (ttbr1_el12): Likewise. (ttbr1_el2): Likewise. (vttbr_el2): Likewise.
2023-11-07aarch64: Add THE system register supportVictor Do Nascimento8-0/+25
Add Binutils support for system registers associated with the Translation Hardening Extension (THE). In doing so, we also add core feature support for THE, enabling its associated feature flag and implementing the necessary feature-checking machinery. Regression tested on aarch64-linux-gnu, no regressions. gas/ChangeLog: * config/tc-aarch64.c (aarch64_features): Add "+the" feature modifier. * doc/c-aarch64.texi (AArch64 Extensions): Update documentation for `the' option. * testsuite/gas/aarch64/sysreg-8.s: Add tests for `the' associated system registers. * testsuite/gas/aarch64/sysreg-8.d: Likewise. include/ChangeLog: * opcode/aarch64.h (enum aarch64_feature_bit): Add AARCH64_FEATURE_THE. opcode/ChangeLog: * aarch64-opc.c (aarch64_sys_ins_reg_supported_p): Add `the' system register check support. * aarch64-sys-regs.def: Add `rcwmask_el1' and `rcwsmask_el1' * aarch64-tbl.h: Define `THE' preprocessor macro.
2023-11-07gdb/arm: remove thumb bit in arm_adjust_breakpoint_addressSimon Marchi1-3/+6
When compiling gdb with -fsanitize=address on ARM, I get a crash in test gdb.arch/arm-disp-step.exp, reproduced easily with: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... ================================================================= ==23295==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xb4a14fd1 at pc 0x01a48871 bp 0xbeab8490 sp 0xbeab8494 Since it doesn't require running the program, it can be reproduced locally on a dev machine other than ARM, after acquiring the test binary. The length of the allocate buffer `buf` is 1, and we try to extract an integer of size 2 from it. The length of 1 comes from the subtraction `bpaddr - boundary`. Normally, on ARM, all instructions are aligned on a multiple of 2, so it's weird for this subtraction to result in 1. In this case, boundary comes from the result of find_pc_partial_function returning 0x549: (gdb) p/x bpaddr $2 = 0x54a (gdb) p/x boundary $3 = 0x549 (gdb) p/x bpaddr - boundary $4 = 0x1 0x549 is the address of the test_call_subr label, 0x548, with the thumb bit enabled. Before doing some math with the address, I think we need to strip the thumb bit, like is done elsewhere (for instance for bpaddr earlier in the same function). I wonder if find_pc_partial_function should do that itself, in order to return an address that is suitable for arithmetic. In any case, that would be a change with a broad impact, so for now just fix the issue locally. After the patch: $ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step -ex "break *test_call_end" Reading symbols from testsuite/outputs/gdb.arch/arm-disp-step/arm-disp-step... Breakpoint 1 at 0x54a: file /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/arm-disp-step.S, line 103. Change-Id: I74fc458dbea0d2c1e1f5eadd90755188df089288 Approved-By: Luis Machado <luis.machado@arm.com>
2023-11-07ld/x86: reduce testsuite dependency on system object filesJan Beulich4-94/+131
PR ld/30722 Tests looking for certain .note-section recorded properties may not involve object files from the underlying platform (e.g. via using the C compiler for linking): Such object files may themselves have similar note sections, and hence they may influence the overall outcome. For now convert just the tests known to be affected by crt*.o coming with "ISA v3 needed" notes. Eventually other tests ought to be converted, too.
2023-11-07Revert "ld x86_64 tests: Accept x86-64-v3 as a needed ISA"Jan Beulich4-3/+10
This reverts commit bf77f42f6708d8b5ba92336d876042826d8d29c1. It wrongly altered testcase expectations; the issue will need taking care of differently.
2023-11-07RISC-V: Add support for XCValu extension in CV32E40PMary Bennett36-0/+787
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html Contributors: Mary Bennett <mary.bennett@embecosm.com> Nandni Jamnadas <nandni.jamnadas@embecosm.com> Pietra Ferreira <pietra.ferreira@embecosm.com> Charlie Keaney Jessica Mills Craig Blackmore <craig.blackmore@embecosm.com> Simon Cook <simon.cook@embecosm.com> Jeremy Bennett <jeremy.bennett@embecosm.com> Helene Chelin <helene.chelin@embecosm.com> bfd/ChangeLog: * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvalu` instruction class. (riscv_multi_subset_supports_ext): Likewise. gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn): Added the necessary operands for the extension. (riscv_ip): Likewise. * doc/c-riscv.texi: Noted XCValu as an additional ISA extension for CORE-V. * testsuite/gas/riscv/cv-alu-boundaries.d: New test. * testsuite/gas/riscv/cv-alu-boundaries.l: New test. * testsuite/gas/riscv/cv-alu-boundaries.s: New test. * testsuite/gas/riscv/cv-alu-fail-march.d: New test. * testsuite/gas/riscv/cv-alu-fail-march.l: New test. * testsuite/gas/riscv/cv-alu-fail-march.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-01.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-01.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-01.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-02.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-02.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-02.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-03.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-03.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-03.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-04.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-04.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-04.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-05.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-05.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-05.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-06.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-06.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-06.s: New test. * testsuite/gas/riscv/cv-alu-fail-operand-07.d: New test. * testsuite/gas/riscv/cv-alu-fail-operand-07.l: New test. * testsuite/gas/riscv/cv-alu-fail-operand-07.s: New test. * testsuite/gas/riscv/cv-alu-insns.d: New test. * testsuite/gas/riscv/cv-alu-insns.s: New test. opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Disassemble xcb operand. * riscv-opc.c: Defined the MASK and added XCValu instructions. include/ChangeLog: * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros for XCValu. * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros for XCValu. (enum riscv_insn_class): Added the XCValu instruction class.
2023-11-07RISC-V: Add support for XCVmac extension in CV32E40PMary Bennett15-0/+643
Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html Contributors: Mary Bennett <mary.bennett@embecosm.com> Nandni Jamnadas <nandni.jamnadas@embecosm.com> Pietra Ferreira <pietra.ferreira@embecosm.com> Charlie Keaney Jessica Mills Craig Blackmore <craig.blackmore@embecosm.com> Simon Cook <simon.cook@embecosm.com> Jeremy Bennett <jeremy.bennett@embecosm.com> Helene Chelin <helene.chelin@embecosm.com> bfd/ChangeLog: * elfxx-riscv.c (riscv_multi_subset_supports): Added `xcvmac` instruction class. (riscv_multi_subset_supports_ext): Likewise. gas/ChangeLog: * config/tc-riscv.c (validate_riscv_insn): Added the necessary operands for the extension. (riscv_ip): Likewise. * doc/c-riscv.texi: Noted XCVmac as an additional ISA extension for CORE-V. * testsuite/gas/riscv/cv-mac-fail-march.d: New test. * testsuite/gas/riscv/cv-mac-fail-march.l: New test. * testsuite/gas/riscv/cv-mac-fail-march.s: New test. * testsuite/gas/riscv/cv-mac-fail-operand.d: New test. * testsuite/gas/riscv/cv-mac-fail-operand.l: New test. * testsuite/gas/riscv/cv-mac-fail-operand.s: New test. * testsuite/gas/riscv/cv-mac-insns.d: New test. * testsuite/gas/riscv/cv-mac-insns.s: New test. opcodes/ChangeLog: * riscv-dis.c (print_insn_args): Disassemble information with the EXTRACT macro implemented. * riscv-opc.c: Defined the MASK and added XCVmac instructions. include/ChangeLog: * opcode/riscv-opc.h: Added corresponding MATCH and MASK macros for XCVmac. * opcode/riscv.h: Added corresponding EXTRACT and ENCODE macros for uimm. (enum riscv_insn_class): Added the XCVmac instruction class.
2023-11-06Remove EXTERN_C and related definesTom Tromey12-36/+32
common-defs.h has a few defines that I suspect were used during the transition to C++. These aren't needed any more, so remove them. Tested by rebuilding. Approved-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-11-07Automatic date update in version.inGDB Administrator1-1/+1
2023-11-06gdb: Update email address for Carl Love in gdb/MAINTAINERSCarl Love1-1/+1
2023-11-06Fix resizing of TUI python windowsHannes Domani1-0/+10
When resizing from a big to small terminal size, and you have a TUI python window that would then be outside of the new size, valgrind shows this error: ==3389== Invalid read of size 1 ==3389== at 0xC3DFEE: wnoutrefresh (lib_refresh.c:167) ==3389== by 0xC3E3C9: wrefresh (lib_refresh.c:63) ==3389== by 0xA9766C: tui_unhighlight_win(tui_win_info*) (tui-wingeneral.c:134) ==3389== by 0x98921C: tui_py_window::rerender() (py-tui.c:183) ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030) ==3389== by 0xA8C2A2: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1033) ==3389== by 0xA8C23C: tui_layout_split::apply(int, int, int, int, bool) (tui-layout.c:1030) ==3389== by 0xA8B1F8: tui_apply_current_layout(bool) (tui-layout.c:81) ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525) ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562) ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234) ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199) ==3389== Address 0x115cc214 is 1,332 bytes inside a block of size 2,240 free'd ==3389== at 0x4A0A430: free (vg_replace_malloc.c:446) ==3389== by 0xC3CF7D: _nc_freewin (lib_newwin.c:121) ==3389== by 0xA8B1C6: tui_apply_current_layout(bool) (tui-layout.c:78) ==3389== by 0xA95CDB: tui_resize_all() (tui-win.c:525) ==3389== by 0xA95D1E: tui_async_resize_screen(void*) (tui-win.c:562) ==3389== by 0x6B855D: invoke_async_signal_handlers() (async-event.c:234) ==3389== by 0xC0CEF8: gdb_do_one_event(int) (event-loop.cc:199) ==3389== by 0x8E40E9: captured_command_loop() (main.c:407) ==3389== by 0x8E5E54: gdb_main(captured_main_args*) (main.c:1324) ==3389== by 0x62AC04: main (gdb.c:39) It's because tui_py_window::m_inner_window still has the outside coordinates, and wnoutrefresh then does an out-of-bounds access. Fix this by resetting m_inner_window on every resize, it will anyways be recreated in the next rerender call. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-11-06Change gdb.base/examine-backwards.exp for AIX.Aditya Vidyadhar Kamath1-4/+4
In AIX unused or constant variables are collected as garbage by the linker and in the dwarf dump an address with all f's in hexadecimal are assigned. Hence the testcase fails with many failures stating it cannot access memory. This patch is a small change to get it working in AIX as well.
2023-11-06ld: =fillexp different behaviors for hexidecimal literalNick Clifton5-1/+89
PR 30865 * ld.texi: Update description of the FILL command. * testsuite/ld-scripts/fill2.d: New test. * testsuite/ld-scripts/fill2.t: New test source. * testsuite/ld-scripts/data.exp: Run the new test.
2023-11-06RISC-V: Make sure rv32q conflict won't affect the fp-q-insns-32 gas testcase.Nelson Chu1-1/+1
Same as commit 4352c0ac04a. gas/ * testsuite/gas/riscv/fp-q-insns-32.d: Set q to v2.2.
2023-11-06RISC-V: Moved out linker internal relocations after R_RISCV_max.Nelson Chu6-108/+101
Just the lightest modifications about this, without any further checks and considering --emit-relocs. We will need to improve it in the future, but first do this to avoid conflicts between linker internal relocations and the new definition of psabi. For example, TLSDESC relocs. Passed riscv-gnu-toolchain regressions, so should be safe enough to commit. Co-authored-by: Tsukasa OI <research_trasio@irq.a4lg.com> bfd/ * reloc.c: Removed linker internal relocations. * bfd-in2.h: Regenerated. * libbfd.h: Regenerated. * elfnn-riscv.c: Defined R_RISCV_DELETE in include/elf/riscv.h. * elfxx-riscv.c (howto_table, howto_table_internal): Moved linker internal relocations from howto_table into howto_table_internal. (riscv_reloc_map): Removed linker internal relocations mapping. (riscv_elf_rtype_to_howto): Return howto of linker internal relocations from howto_table_internal. include/ * elf/riscv.h: Defined linker internal relocations after R_RISCV_max.
2023-11-06[gdb/testsuite] Fix gdb.dwarf2/dw2-gas-workaround.expTom de Vries1-1/+1
Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp: - passes when gdb is configured using $(cd ../src; pwd)/configure, but - fails when using ../src/configure. Fix this by making the matching more precise: ... - -re -wrap "$objdir.*" { + -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" { ... such that we only fail on the line: ... [symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \ /data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M ... Reported-By: Carl Love <cel@us.ibm.com>
2023-11-06Automatic date update in version.inGDB Administrator1-1/+1
2023-11-05Pre-read DWZ file in DWARF readerTom Tromey5-23/+31
While working on background reading of DWARF, I came across the DWZ-reading code. This code can query the user (via the debuginfod support) -- something that cannot be done off the main thread. Looking into it, I realized that this code can be run much earlier, avoiding this problem. Digging a bit deeper, I also found a discrepancy here between how the DWARF reader works in "readnow" mode as compared to the normal modes. This patch cleans this up by trying to read the DWZ file earlier, and also by having the DWARF reader convert any exception here into a warning. This unifies the various cases, but also makes it so that errors do not prevent gdb from continuing on to the extent possible. Regression tested on x86-64 Fedora 38.
2023-11-05Automatic date update in version.inGDB Administrator1-1/+1
2023-11-04Automatic date update in version.inGDB Administrator1-1/+1
2023-11-03Remove unused declarationTom Tromey1-1/+0
I found a declaration in py-stopevent.h for which there is no definition. This patch removes it.
2023-11-03gdbsupport: mark array_view::slice with [[nodiscard]]Simon Marchi1-0/+2
I (almost) had a bug where I did: buffer.slice (...) but I meant: buffer = buffer.slice (...) The first one does nothing, it creates a new array_view but without using it, it's useless. Mark the slice methods with [[nodiscard]] (which is standard C++17) so that error would generate a warning. I guess that many functions could be marked as nodiscard, essentially function that is pure (doesn't have side-effects). But this one seems particularly easy to mis-use. Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb Approved-By: Tom Tromey <tom@tromey.com>
2023-11-03gdbsupport: record and print failed selftest namesSimon Marchi1-4/+15
Since "maint selftest" now runs quite a lot of tests (especially in an all-targets build), I thought it would be useful to print a summary at the end of what failed. So, implement that. Print the summary before the "Ran %d unit tests, %zu failed\n" line, so that that one remains the last line, and the gdb.gdb/unittest.exp doesn't need to be changed. The output looks like (if I force a failure in a test): (gdb) maint selftest ... Running selftest value_copy. Running selftest xml_escape_text. Running selftest xml_escape_text_append. Failures: aarch64-analyze-prologue Ran 4134 unit tests, 1 failed (gdb) Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e Approved-By: Tom Tromey <tom@tromey.com>
2023-11-03gas: correct ignoring of C-style number suffixesJan Beulich4-4/+116
First of all the respective original changes didn't deal with just 0 having such a suffix - this needs additional logic outside of integer_constant(). Further bogus suffixes having more than two L-s were accepted, while valid suffixes with U following the L(s) weren't. Finally respective tests were introduced for Sparc only. Reviewed-by: Neal Frager <neal.frager@amd.com>
2023-11-03RISC-V: reduce redundancy in load/store macro insn handlingJan Beulich3-123/+28
Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and FS{H,W,D,Q} the sole difference between the handling is the insn mnemonic passed to the common handling functions. The intended mnemonic, however, can easily be retrieved. Furthermore leverags that Sx and FSx are then handled identically, too, and hence their cases can also be folded.
2023-11-03RISC-V: Lx/Sx macro insn testsJan Beulich2-0/+70
Make sure these (continue to) work as intended.
2023-11-03RISC-V: add F- and D-extension testcasesJan Beulich10-0/+1111
Make sure future changes won't regress any of this. Also cover the FLH and FSH macro insns of the Zfh extension.
2023-11-03RISC-V: make FLQ/FSQ macro-insns workJan Beulich5-0/+516
When support for the Q extension was added, the libopcodes side of these macro-insns was properly covered, but no backing support in gas was added. In new testcases cover not just these, but all Q-extension insns.
2023-11-03Automatic date update in version.inGDB Administrator1-1/+1
2023-11-02[gdb/tdep] Fix nr array elements in ppc64_aggregate_candidateTom de Vries1-1/+5
On AlmaLinux 9.2 powerpc64le I run into: ... (gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector finish^M Run till exit from #0 pck.create_small_float_vector () at pck.adb:30^M 0x00000000100022d4 in p () at p.adb:25^M 25 Vector := Create_Small_Float_Vector;^M Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M (gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector ... while this is expected: ... Value returned is $3 = (4.25, 4.25)^M ... The problem is here in ppc64_aggregate_candidate: ... if (!get_array_bounds (type, &low_bound, &high_bound)) return -1; count *= high_bound - low_bound ... The array type (containing 2 elements) is: ... type Small_Float_Vector is array (1 .. 2) of Float; ... so we have: ... (gdb) p low_bound $1 = 1 (gdb) p high_bound $2 = 2 ... but we calculate the number of elements in the array using "high_bound - low_bound", which is 1. Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous aggregate. Fix this by calculating the number of elements in the array by using "high_bound - low_bound + 1" instead. Furthermore, high_bound can (in general, though perhaps not here) also be smaller than low_bound, so to be safe take that into account as well: ... LONGEST nr_array_elements = (low_bound > high_bound ? 0 : (high_bound - low_bound + 1)); count *= nr_array_elements; ... Tested on powerpc64le-linux. Approved-By: Ulrich Weigand <uweigand@de.ibm.com> PR tdep/31015 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015
2023-11-02aarch64: Add GCS system registers.Srinath Parvathaneni5-0/+83
This patch adds support for 10 new AArch64 system registers (gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3, gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3), which are enabled on using Guarded Control Stack (+gcs flag) feature.
2023-11-02aarch64: Add support for GCSB DSYNC instruction.Srinath Parvathaneni13-2299/+2295
This patch adds support for Guarded control stack data synchronization instruction (GCSB DSYNC). This instruction is allocated to existing HINT space and uses the HINT number 19 and to match this an entry is added to the aarch64_hint_options array.