aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-14gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_writeSimon Marchi3-130/+61
Make i386 and amd64 use the new gdbarch_pseudo_register_write. This fixes writing to pseudo registers in non-current frames for those architectures. Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: add gdbarch_pseudo_register_write that takes a frameSimon Marchi7-2/+167
Add a new variant of gdbarch_pseudo_register_write that takes a frame_info in order to write raw registers. Use this new method when available: - in put_frame_register, when trying to write a pseudo register to a given frame - in regcache::cooked_write No implementation is migrated to use this new method (that will come in subsequent patches), so no behavior change is expected here. The objective is to fix writing pseudo registers to non-current frames. See previous commit "gdb: read pseudo register through frame" for a more detailed explanation. Change-Id: Ie7fe364a15a4d86c2ecb09de2b4baa08c45555ac Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: rename gdbarch_pseudo_register_write to ↵Simon Marchi28-54/+90
gdbarch_deprecated_pseudo_register_write The next patch introduces a new variant of gdbarch_pseudo_register_write that takes a frame instead of a regcache for implementations to write raw registers. Rename to old one to make it clear it's deprecated. Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: change parameter name in frame_unwind_register_unsigned declarationSimon Marchi1-1/+1
For consistency with the declarations around. Change-Id: I398266a61eae6e93fb7e306923009da9dd7f8fc4 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: read pseudo register through frameSimon Marchi12-285/+322
Change gdbarch_pseudo_register_read_value to take a frame instead of a regcache. The frame (and formerly the regcache) is used to read raw registers needed to make up the pseudo register value. The problem with using the regcache is that it always provides raw register values for the current frame (frame 0). Let's say the user wants to read the ebx register on amd64. ebx is a pseudo register, obtained by reading the bottom half (bottom 4 bytes) of the rbx register, which is a raw register. If the currently selected frame is frame 0, it works fine: (gdb) frame 0 #0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36 36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S (gdb) p/x $ebx $1 = 0x24252627 (gdb) p/x $rbx $2 = 0x2021222324252627 But if the user is looking at another frame, and the raw register behind the pseudo register has been saved at some point in the call stack, then we get a wrong answer: (gdb) frame 1 #1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56 56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S (gdb) p/x $ebx $3 = 0x24252627 (gdb) p/x $rbx $4 = 0x1011121314151617 Here, the value of ebx was computed using the value of rbx in frame 0 (through the regcache), it should have been computed using the value of rbx in frame 1. In other to make this work properly, make the following changes: - Make dwarf2_frame_prev_register return nullptr if it doesn't know how to unwind a register and that register is a pseudo register. Previously, it returned `frame_unwind_got_register`, meaning, in our example, "the value of ebx in frame 1 is the same as the value of ebx in frame 0", which is obviously false. Return nullptr as a way to say "I don't know". - In frame_unwind_register_value, when prev_register (for instance dwarf2_frame_prev_register) returns nullptr, and we are trying to read a pseudo register, try to get the register value through gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read. If using gdbarch_pseudo_register_read, the behavior is known to be broken. Implementations should be migrated to use gdbarch_pseudo_register_read_value to fix that. - Change gdbarch_pseudo_register_read_value to take a frame_info instead of a regcache, update implementations (aarch64, amd64, i386). In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that uses a frame instead of a regcache. The version using the regcache is still used by i386_pseudo_register_write. It will get removed in a subsequent patch. - Add some helpers in value.{c,h} to implement the common cases of pseudo registers: taking part of a raw register and concatenating multiple raw registers. - Update readable_regcache::{cooked_read,cooked_read_value} to pass the current frame to gdbarch_pseudo_register_read_value. Passing the current frame will give the same behavior as before: for frame 0, raw registers will be read from the current thread's regcache. Notes: - I do not plan on changing gdbarch_pseudo_register_read to receive a frame instead of a regcache. That method is considered deprecated. Instead, we should be working on migrating implementations to use gdbarch_pseudo_register_read_value instead. - In frame_unwind_register_value, we still ask the unwinder to try to unwind pseudo register values. It's apparently possible for the debug info to provide information about [1] pseudo registers, so we want to try that first, before falling back to computing them ourselves. [1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/ Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: add value::allocate_registerSimon Marchi3-5/+24
Add value::allocate_register, to facilitate allocating a value representing a register in a given frame (or rather, in the given frame's previous frame). It will be used in a subsequent patch. I changed one relatively obvious spot that could use it, to at least exercise the code path. Change-Id: Icd4960f5e471a74b657bb3596c88d89679ef3772 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make get_frame_register_bytes take the next frameSimon Marchi10-55/+50
Similar to the previous patches, change get_frame_register_bytes to take the "next frame" instead of "this frame". Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register_bytes take the next frameSimon Marchi5-36/+31
Similar to the previous patches, change put_frame_register_bytes to take the "next frame" instead of "this frame". Change-Id: I27bcb26573686d99b231230823cff8db6405a788 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take the next frameSimon Marchi9-19/+24
Similar to the previous patches, change put_frame_register to take the "next frame" instead of "this frame". Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: remove frame_registerSimon Marchi1-31/+8
I was going to change frame_register to take the "next frame", but I realized that doing so would make it a useless wrapper around frame_register_unwind. So, just remove frame_register and replace uses with frame_register_unwind. Change-Id: I185868bc69f8e098124775d0550d069220a4678a Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi17-49/+53
Some functions related to the handling of registers in frames accept "this frame", for which we want to read or write the register values, while other functions accept "the next frame", which is the frame next to that. The later is needed because we sometimes need to read register values for a frame that does not exist yet (usually when trying to unwind that frame-to-be). value_of_register and value_of_register_lazy both take "this frame", even if what they ultimately want internally is "the next frame". This is annoying if you are in a spot that currently has "the next frame" and need to call one of these functions (which happens later in this series). You need to get the previous frame only for those functions to get the next frame again. This is more manipulations, more chances of mistake. I propose to change these functions (and a few more functions in the subsequent patches) to operate on "the next frame". Things become a bit less awkward when all these functions agree on which frame they take. So, in this patch, change value_of_register_lazy and value_of_register to take "the next frame" instead of "this frame". This adds a lot of get_next_frame_sentinel_okay, but if we convert the user registers API to also use "the next frame" instead of "this frame", it will get simple again. Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take an array_viewSimon Marchi9-24/+35
Change put_frame_register to take an array_view instead of a raw pointer. Add an assertion to verify that the number of bytes we try to write matches the length of the register. Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: fix bugs in {get,put}_frame_register_bytesSimon Marchi1-40/+23
I found this only by inspection: the myaddr pointer in {get,put}_frame_register_bytes is reset to `buffer.data ()` at each iteration. This means that we will always use the bytes at the beginning of `buffer` to read or write to the registers, instead of progressing in `buffer`. Fix this by re-writing the functions to chip away the beginning of the buffer array_view as we progress in reading or writing the data. These bugs was introduced almost 3 years ago [1], and yet nobody complained. I'm wondering which architecture relies on that register "overflow" behavior (reading or writing multiple consecutive registers with one {get,put}_frame_register_bytes calls), and in which situation. I find these functions a bit dangerous, if a caller mis-calculates things, it could end up silently reading or writing to the next register, even if it's not the intent. If I could change it, I would prefer to have functions specifically made for that ({get,put}_frame_register_bytes_consecutive or something like that) and make {get,put}_frame_register_bytes only able to write within a single register (which I presume represents most of the use cases of the current {get,put}_frame_register_bytes). If a caller mis-calculates things and an overflow occurs while calling {get,put}_frame_register_bytes, it would hit an assert. The problem is knowing which callers rely on the overflow behavior and which don't. [1] https://gitlab.com/gnutools/binutils-gdb/-/commit/bdec2917b1e94c7198ba39919f45060067952f43 Change-Id: I43bd4a9f7fa8419d388a2b20bdc57d652688ddf8 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-12-14gdb: change regcache interface to use array_viewSimon Marchi9-271/+457
Change most of regcache (and base classes) to use array_view when possible, instead of raw pointers. By propagating the use of array_view further, it enables having some runtime checks to make sure the what we read from or write to regcaches has the expected length (such as the one in the `copy(array_view, array_view)` function. It also integrates well when connecting with other APIs already using gdb::array_view. Add some overloads of the methods using raw pointers to avoid having to change all call sites at once (which is both a lot of work and risky). I tried to do this change in small increments, but since many of these functions use each other, it ended up simpler to do it in one shot than having a lot of intermediary / transient changes. This change extends into gdbserver as well, because there is some part of the regcache interface that is shared. Changing the reg_buffer_common interface to use array_view caused some build failures in nat/aarch64-scalable-linux-ptrace.c. That file currently "takes advantage" of the fact that reg_buffer_common::{raw_supply,raw_collect} operates on `void *`, which IMO is dangerous. It uses raw_supply/raw_collect directly on uint64_t's, which I guess is fine because it is expected that native code will have the same endianness as the debugged process. To accomodate that, add some overloads of raw_collect and raw_supply that work on uint64_t. This file also uses raw_collect and raw_supply on `char` pointers. Change it to use `gdb_byte` pointers instead. Add overloads of raw_collect and raw_supply that work on `gdb_byte *` and make an array_view on the fly using the register's size. Those call sites could be converted to use array_view with not much work, in which case these overloads could be removed, but I didn't want to do it in this patch, to avoid starting to dig in arch-specific code. During development, I inadvertently changed reg_buffer::raw_compare's behavior to not accept an offset equal to the register size. This behavior (effectively comparing 0 bytes, returning true) change was caught by the AArch64 SME core tests. Add a selftest to make sure that this raw_compare behavior is preserved in the future. Change-Id: I9005f04114543ddff738949e12d85a31855304c2 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: simplify conditions in regcache::{read,write,raw_collect,raw_supply}_partSimon Marchi1-12/+12
Make a few simplifications in these functions. 1. When checking if we need to do nothing, if the length is 0, we don't need to do anything, regardless of the value of offset. Remove the offset check. 2. When check if transferring the whole register, if the length is equal to the register size, then we transfer the whole register, no need to check the offset. Remove the offset check. 3. In the gdb_asserts, it is unnecessary to check for: offset <= reg_size given that right after we check for: len >= 0 && offset + len <= reg_size If `offset + len` is <= reg_size and len is >= 0, then necessarily offset is <= reg_size. Remove the `offset <= reg_size` check. Change-Id: I30a73acdc7bf432c45a07f5f177224d1cdc298e8 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make store_integer take an array_viewSimon Marchi2-17/+38
Change store_integer, store_signed_integer and store_unsigned_integer to accept an array_view. Add some backwards compatibility overloads to avoid changing all callers at once. Change-Id: Ibb1381228ab1cb65fc7e2e4b92cf9ab1047cdc03 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: use reg_buffer_common throughout gdbsupport/common-regcache.hSimon Marchi13-42/+56
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-12-14gdb: don't handle i386 k registers as pseudo registersSimon Marchi1-23/+0
I think that i386 k registers are raw registers, and therefore shouldn't be handled in the various functions handling pseudo registers. What tipped me off is the code in i386_pseudo_register_read_into_value: else if (i386_k_regnum_p (gdbarch, regnum)) { regnum -= tdep->k0_regnum; /* Extract (always little endian). */ status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf); We take regnum (the pseudo register number we want to read), subtract k0_regnum, add k0_regnum, and pass the result to raw_read. So we would end up calling raw_read with the same regnum as the function received which is supposedly a pseudo register number. Other hints are: - The command `maint print raw-registers` shows the k registers. - Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be called. - There's code in i387-tdep.c to save/restore the k registers. Remove handling of the k registers from: - i386_pseudo_register_read_into_value - i386_pseudo_register_write - i386_ax_pseudo_register_collect Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562 Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-12-14Allow calling of variadic C++ functionsHannes Domani5-6/+55
Currently, it's not possible to call a variadic C++ function: ``` (gdb) print sum_vararg_int(1, 10) Cannot resolve function sum_vararg_int to any overloaded instance (gdb) print sum_vararg_int(2, 20, 30) Cannot resolve function sum_vararg_int to any overloaded instance ``` It's because all additional arguments get the TOO_FEW_PARAMS_BADNESS rank by rank_function, which disqualifies the function. To fix this, I've created the new VARARG_BADNESS rank, which is used only for additional arguments of variadic functions, allowing them to be called: ``` (gdb) print sum_vararg_int(1, 10) $1 = 10 (gdb) print sum_vararg_int(2, 20, 30) $2 = 50 ``` Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28589 Approved-By: Tom Tromey <tom@tromey.com>
2023-12-14RISC-V: Fix the wrong encoding and operand of the XTheadFmv extension.Jin Ma4-8/+8
The description of instructions 'th.fmv.hw.x' and 'th.fmv.x.hw' of the XTheadFmv extension in T-Head specific is incorrect, and it also has some impact on the implementation of the binutils, so this patch corrects this. For details see: https://github.com/T-head-Semi/thead-extension-spec/pull/34 gas/ChangeLog: * testsuite/gas/riscv/x-thead-fmv.d: Correct test. * testsuite/gas/riscv/x-thead-fmv.s: Likewise. include/ChangeLog: * opcode/riscv-opc.h (MATCH_TH_FMV_HW_X): Correct coding. (MASK_TH_FMV_HW_X): Likewise. (MATCH_TH_FMV_X_HW): Likewise. (MASK_TH_FMV_X_HW): Likewise. opcodes/ChangeLog: * riscv-opc.c: Correct operands.
2023-12-14Remove redundant Byte, Word, Dword and Qword from insn templates.Cui, Lili1-123/+123
opcodes/ChangeLog: * i386-opc.tbl: Remove redundant Byte, Word, Dword and Qword.
2023-12-14Automatic date update in version.inGDB Administrator1-1/+1
2023-12-13Use unique_xmalloc_ptr in explicit_location_specTom Tromey7-81/+83
This changes explicit_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-13Use unique_xmalloc_ptr in linespec_location_specTom Tromey4-17/+12
This changes linespec_location_spec to use unique_xmalloc_ptr, removing some manual memory management. Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-13Update Make const_1_mode print $1 in AT&T syntaxH.J. Lu1-1/+1
commit b70a487d5945b13e5ab503be4fc37b964819ec0e Author: Cui, Lili <lili.cui@intel.com> Date: Wed Dec 13 06:07:36 2023 +0000 Make const_1_mode print $1 in AT&T syntax changes disassembler output from d1 f8 sar %eax to d1 f8 sar $1,%eax Adjust pe-x86-64-6.od accordingly. * testsuite/ld-x86-64/pe-x86-64-6.od: Adjusted.
2023-12-13[gdb/tui] add SingleKey bindings for reverse execution commandsMagne Hov2-0/+30
The bindings for the reverse execution commands are the same letters as the forward execution command, but with the opposite case. This way one can simply hold down the Shift modifier key or tap the Caps Lock key to change the direction of execution. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
2023-12-13gdb/python: avoid use of _PyOS_ReadlineTStateAndrew Burgess1-6/+4
In python/py-gdb-readline.c we make use of _PyOS_ReadlineTState, however, this variable is no longer public in Python 3.13, and so GDB no longer builds. We are making use of _PyOS_ReadlineTState in order to re-acquire the Python Global Interpreter Lock (GIL). The _PyOS_ReadlineTState variable is set in Python's outer readline code prior to calling the user (GDB) supplied readline callback function, which for us is gdbpy_readline_wrapper. The gdbpy_readline_wrapper function is called without the GIL held. Instead of using _PyOS_ReadlineTState, I propose that we switch to calling PyGILState_Ensure() and PyGILState_Release(). These functions will acquire the GIL based on the current thread. I think this should be sufficient; I can't imagine why we'd be running gdbpy_readline_wrapper on one thread on behalf of a different Python thread.... that would be unexpected I think. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-13gdb: move gdbpy_gil into python-internal.hAlexandra Hájková2-24/+24
Move gdbpy_gil class into python-internal.h, the next commit wants to make use of this class from a file other than python.c. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-13gdb: improve error reporting for 'save gdb-index'Andrew Burgess4-44/+198
While making recent changes to 'save gdb-index' command I triggered some errors -- of the kind a user might be expected to trigger if they do something wrong -- and I didn't find GDB's output as helpful as it might be. For example: $ gdb -q /tmp/hello.x ... (gdb) save gdb-index /non_existing_dir Error while writing index for `/tmp/hello': mkstemp: No such file or directory. That the error message mentions '/tmp/hello', which does exist, but doesn't mention '/non_existing_dir', which doesn't is, I think, confusing. Also, I find the 'mkstemp' in the error message confusing for a user facing error. A user might not know what mkstemp means, and even if they do, that it appears in the error message is an internal GDB detail. The user doesn't care what function failed, but wants to know what was wrong with their input, and what they should do to fix things. Similarly, for a directory that does exist, but can't be written to: (gdb) save gdb-index /no_access_dir Error while writing index for `/tmp/hello': mkstemp: Permission denied. In this case, the 'Permission denied' might make the user thing there is a permissions issue with '/tmp/hello', which is not the case. After this patch, the new errors are: (gdb) save gdb-index /non_existing_dir Error while writing index for `/tmp/hello': `/non_existing_dir': No such file or directory. and: (gdb) save gdb-index /no_access_dir Error while writing index for `/tmp/hello': `/no_access_dir': Permission denied. we also have: (gdb) save gdb-index /tmp/not_a_directory Error while writing index for `/tmp/hello': `/tmp/not_a_directory': Is not a directory. I think these do a better job of guiding the user towards fixing the problem. I've added a new test that exercises all of these cases, and also checks the case where a user tries to use an executable that already contains an index in order to generate an index. As part of the new test I've factored out some code from ensure_gdb_index (lib/gdb.exp) into a new proc (get_index_type), which I've then used in the new test. I've confirmed that all the tests that use ensure_gdb_index still pass. During review it was pointed out that the testsuite proc have_index (lib/gdb.exp) is similar to the new get_index_type proc, so I've rewritten have_index to also use get_index_type, I've confirmed that all the tests that use have_index still pass. Nothing that worked correctly before this patch should give an error after this patch; I've only changed the output when the user was going to get an error anyway. Reviewed-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
2023-12-13Make const_1_mode print $1 in AT&T syntaxCui, Lili14-128/+130
Make const_1_mode print $1 in AT&T syntax, otherwise there will be correctness issues when it is extended to support APX NDD, gas/ChangeLog: * testsuite/gas/i386/intel.d: Adjust testcase. * testsuite/gas/i386/lfence-load.d: Ditto. * testsuite/gas/i386/noreg16-data32.d: Ditto. * testsuite/gas/i386/noreg16.d: Ditto. * testsuite/gas/i386/noreg32-data16.d: Ditto. * testsuite/gas/i386/noreg32.d: Ditto. * testsuite/gas/i386/noreg64-data16.d: Ditto. * testsuite/gas/i386/noreg64-rex64.d: Ditto. * testsuite/gas/i386/noreg64.d: Ditto. * testsuite/gas/i386/opcode-suffix.d: Ditto. * testsuite/gas/i386/opcode.d: Ditto. * testsuite/gas/i386/x86-64-lfence-load.d: Ditto. * testsuite/gas/i386/x86-64-opcode.d: Ditto. opcodes/ChangeLog: * i386-dis.c (OP_I): Make const_1_mode print $1 in AT&T syntax.
2023-12-13Clean base_reg and assign correct values to regs for input_output_operand (%dx).Cui, Lili1-0/+2
For special processing of input and output operands (%dx), the state of some variables needs to be cleaned. gas/ChangeLog: * config/tc-i386.c (i386_att_operand): Assign values to regs and clean i.base_reg for input output operand (%dx).
2023-12-13Automatic date update in version.inGDB Administrator1-1/+1
2023-12-12gdbserver/win32: fix crash on detachStefano Moioli1-1/+1
this patch fixes a crash in gdbserver whenever a process is detached. the crash is caused by `detach` calling `remove_process` before `win32_clear_inferiors` error message: Detaching from process 184 ../../gdbserver/inferiors.cc:160: A problem internal to GDBserver has been detec ted. remove_process: Assertion `find_thread_process (process) == NULL' failed. This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-12Fix gdb.FinishBreakpoint when returning to an inlined functionHannes Domani3-1/+41
Currently, when creating a gdb.FinishBreakpoint in a function called from an inline frame, it will never be hit: ``` (gdb) py fb=gdb.FinishBreakpoint() Temporary breakpoint 1 at 0x13f1917b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47. (gdb) c Continuing. Thread-specific breakpoint 1 deleted - thread 1 no longer in the thread list. [Inferior 1 (process 1208) exited normally] ``` The reason is that the frame_id of a breakpoint has to be the ID of a real frame, ignoring any inline frames. With this fixed, it's working correctly: ``` (gdb) py fb=gdb.FinishBreakpoint() Temporary breakpoint 1 at 0x13f5617b4: file C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c, line 47. (gdb) c Continuing. Breakpoint 1, increase_inlined (a=0x40fa5c) at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.python/py-finish-breakpoint.c:47 (gdb) py print(fb.return_value) -8 ``` Approved-By: Tom Tromey <tom@tromey.com>
2023-12-12Support dynamically computed convenience variables in get_internalvar_integerHannes Domani3-0/+28
When using $_thread in info threads to showonly the current thread, you get this error: ``` (gdb) info thread $_thread Convenience variable must have integer value. Args must be numbers or '$' variables. ``` It's because $_thread is a dynamically computed convenience variable, which isn't supported yet by get_internalvar_integer. Now the output looks like this: ``` (gdb) info threads $_thread Id Target Id Frame * 1 Thread 10640.0x2680 main () at C:/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/gdbvars.c:21 ``` Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17600 Approved-By: Tom Tromey <tom@tromey.com>
2023-12-12Support rodata in flash for more AVR devicesGeorg-Johann Lay9-5/+202
PR 31124 * Makefile.am (ALL_EMULATION_SOURCES): Add eavrxmega2_flmap.c and eavrxmega4_flmap.c. * Makefile.in: Regenerate. * configure.tgt: Add eavrxmega2_flmap and eavrxmega4_flmap to avr's targ_extra_emuls list. * emulparams/avrxmega2.sh (MAYBE_FLMAP): Define. * emulparams/avrxmega2_flmap.sh: New file. * emulparams/avrxmega4.sh (MAYBE_FLMAP): Define. * emulparams/avrxmega4_flmap.sh: New file. * scripttempl/avr.sc: Add support for HAVE_FLMAP.
2023-12-12Fix whitespace snafu in tc-riscv.cNick Clifton1-5/+5
2023-12-12RISC-V: Emit R_RISCV_RELAX for the la/lga pseudo instructionRui Ueyama3-0/+26
Some psABIs define a relaxation to turn a GOT load into a PC-relative address materialization. For example, the AArch64's psABI allows adrp+ldr to be rewritten to nop+adr to eliminate the memory load. This patch is part of the effort to make such optimization possible for RISC-V. For RISC-V, we use the la assembly pseudo instruction to load a symbol address from the GOT. The pseudo instruction is expanded to auipc+ld. If the address loaded by the instruction pair is actually a PC-relative link-time constant, we want the linker to rewrite the instruction pair with auipc+addi. We can't rewrite all existing auipc+ld pairs with auipc+addi in the linker because there might be code that jumps to the middle of the instruction pair. That should be extremely rare, if ever exists, but you can at least in theory write a program in assembly that jumps to the ld instruction of the instruction pair. We need a marker to identify that an auipc+ld can be safely relaxed (i.e. they are emitted for la). This patch is to annotate R_RISCV_GOT_HI20 with R_RISCV_RELAX only when the relocation is emitted for the la pseudo instruction. The linker will use it as a signal that the instruction pair can be safely relaxed. Proposal to the RISC-V psABI: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/397 gas/ * config/tc-riscv.c (source_macro): New static int variable. The identifier of the assembler macro we are expanding, if any. (append_insn): Updated source_macro to tc_fix_data, to record which macro expands, if any. (macro): Record which macro expands into source_macro. Reset source_macro to -1 at the end. (md_apply_fix): Apply R_RISCV_RELAX if pcrel_got_hi is expanded from macro LA/LGA. * config/tc-riscv.h (struct riscv_fix, TC_FIX_TYPE, TC_INIT_FIX_DATA): Defined to record source_macro into fixups for riscv target. * testsuite/gas/riscv/la-variants.d: Updated.
2023-12-12RISC-V: Resolve PCREL_HI20/LO12_I/S fixups with local symbols while `-mno-relax'Lifang Xia5-0/+187
In the scenario of generating .ko files, the kernel does not relax the .ko files. However, due to the large amount of relax and local relocation information, this increases the size of the .ko files. In this patch, it will finish the fixup of the local relocations while with `-mno-relax' option. This can reduce the size of the relocation table. The implemntation is based on the code from bfd/elfnn-riscv.c. We probably can move the code to bfd/elfxx-riscv.c, so that can reduce duplicate code, just like what we did for the architecture parser. Besides, maybe not only pcrel_hi/lo12 relocation with local symbols can be resolved at assembler time. Other pc-relative relocation, like branch, may also be able to perform related optimizations. Passed the gcc/binutils regressions of riscv-gnu-toolchain. gas/ * config/tc-riscv.c (riscv_pcrel_hi_reloc): New structure. Record all PC-relative high-part relocation that we have encountered to help us resolve the corresponding low-part relocation later. (riscv_pcrel_hi_fixup_hash): The hash table to record pcrel_hi fixups. (riscv_pcrel_fixup_hash): New function. Likewise. (riscv_pcrel_fixup_eq): Likewise. (riscv_record_pcrel_fixup): Likewise. (md_begin): Init pcrel_hi hash table. (md_apply_fix): For PCREL_HI20 relocation, do fixup and record the pcrel_hi relocs, mark as done while with `-mno-relax'. For PCREL_LO12_I/S relocation, do fixup and mark as done while with `-mno-relax'. (riscv_md_end): New function. Free pcrel_hi hash table. * config/tc-riscv.h (md_end): Define md_end with riscv_md_end. gas/ * testsuite/gas/riscv/fixup-local*: New tests.
2023-12-12Automatic date update in version.inGDB Administrator1-1/+1
2023-12-11Implement DAP cancellationTom Tromey4-3/+177
This implements DAP cancellation. A new object is introduced that handles the details of cancellation. While cancellation is inherently racy, this code attempts to make it so that gdb doesn't inadvertently cancel the wrong request. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30472 Approved-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Catch KeyboardInterrupt in send_gdb_with_responseTom Tromey1-2/+2
Cancellation will generally be seen by the DAP code as a KeyboardInterrupt. However, this derives from BaseException and not Exception, so a small change is needed to send_gdb_with_response, to forward the exception to the DAP server thread. Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Rename a couple of DAP procs in the testsuiteTom Tromey1-5/+5
This renames a couple of DAP procs in the testsuite, to clarify that they are now exported. The cancellation test will need these. Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Introduce gdb.interruptTom Tromey3-0/+33
DAP cancellation needs a way to interrupt whatever is happening on gdb's main thread -- whether that is the inferior, a gdb CLI command, or Python code. This patch adds a new gdb.interrupt() function for this purpose. It simply sets the quit flag and lets gdb do the rest. No tests in this patch -- instead this is tested via the DAP cancellation tests. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Move DAP JSON reader to its own threadTom Tromey1-2/+13
This changes the DAP server to move the JSON reader to a new thread. This is key to implementing request cancellation, as now requests can be read while an earlier one is being serviced. Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Clean up handling of DAP not-stopped responseTom Tromey1-1/+10
This patch introduces a new NotStoppedException type and changes the DAP implementation of "not stopped" to use it. I was already touching some code in this area and I thought this looked a little cleaner. This also has the advantage that we can now choose not to log the exception -- previously I was sometimes a bit alarmed when seeing this in the logs, even though it is harmless. Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
2023-12-11Simplify DAP stop-reason codeTom Tromey4-37/+76
Now that gdb adds stop-reason details to stop events, we can simplify the DAP code to emit correct stop reasons in its own events. For the most part a simple renaming of gdb reasons is sufficient; however, "pause" must still be handled specially.
2023-12-11Emit stop reason details in Python stop eventsTom Tromey8-15/+90
This changes Python stop events to carry a "details" dictionary, that holds any relevant information about the stop. The details are constructed using more or less the same procedure as is done for MI. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13587 Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2023-12-11Move py_ui_out to a new headerTom Tromey2-128/+154
This moves the declaration of py_ui_out to a new header, so that it can more readily be used by other code.
2023-12-11[gdb/testsuite] Fix $eol regexp usage in some test-casesTom de Vries3-13/+13
Commit cff71358132 ("gdb/testsuite: tighten up some end-of-line patterns") replaced: ... set eol "\[\r\n\]+" ... with the more strict: ... set eol "\r\n" ... in a few test-cases, but didn't update all uses of eol accordingly. Fix this in three gdb.ada test-cases. Tested on x86_64-linux. Approved-By: Andrew Burgess <aburgess@redhat.com>
generated by cgit v1.1 at 2024-12-19 11:35:23 +0000