Jan Beulich [Fri, 24 Nov 2023 08:53:15 +0000 (09:53 +0100)]
RISC-V: disallow x0 with certain macro-insns
While for some of the macro insns using x0 is kind of okay, as they
would merely resolve to a sequence of hint insns (and hence not cause
misbehavior at runtime), several of them have the degenerate AUIPC
followed by a load, store, or branch using other than the designated
symbol as address and hence causing runtime issues. Refuse to assemble
those, leveraging that the matching function so far wasn't really used
for macro insns: NULL is now allowed, indicating a match (which imo is
preferable over converting match_never() to match_always()), while
other matching functions now (also) used for macro insns need to avoid
calling match_opcode().
Note that for LA the restriction is slightly too strict: In non-PIC mode
using x0 would be okay-ish as per above (as it's just LLA there). Yet
libopcodes doesn't know what mode gas is presently assembling for, so we
want to err on the safe side.
Jens Remus [Thu, 23 Nov 2023 14:48:59 +0000 (15:48 +0100)]
s390: Correct prno instruction name
IBM z13 (arch11) introduced ppno (Perform Pseudorandom Number Operation).
IBM z14 (arch12) introduced prno (Perform Random Number Operation) and
deprecated ppno.
Jens Remus [Thu, 23 Nov 2023 14:48:15 +0000 (15:48 +0100)]
s390: Add missing extended mnemonics
Add extended mnemonics specified in the z/Architecture Principles of
Operation [1] and z/Architecture Reference Summary [2], that were
previously missing from the opcode table.
The following added extended mnemonics are synonyms to a base mnemonic
and therefore disassemble into their base mnemonic:
jc, jcth, lfi, llgfi, llghi
The following added extended mnemonics are more specific than their base
mnemonic and therefore disassemble into the added extended mnemonic:
risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt
The following added extended mnemonics are more specific than their base
mnemonic, but disassemble into their base mnemonic due to design
constraints:
notr, notgr
The missing extended mnemonic jl* conditional jump long flavors cannot
be added, as they would clash with the existing non-standard extended
mnemonic j* conditional jump flavors jle and jlh. The missing extended
mnemonic jlc jump long conditional is not added, as the related jl*
flavors cannot be added.
Note that these missing jl* conditional jump long flavors are already
defined as non-standard jg* flavors instead. While the related missing
extended mnemonic jlc could be added as non-standard jgc instead it is
forgone in favor of not adding further non-standard mnemonics.
The missing extended mnemonics sllhh, sllhl, slllh, srlhh, srlhl, and
srllh cannot be implemented using the current design, as they require
computed operands. For that reason the following missing extended
mnemonics are not added as well, as they fall into the same category of
instructions that operate on high and low words of registers. They
should better be added together, not to confuse the user, which of those
instructions are currently implemented or not.
lhhr, lhlr, llhfr, llchhr, llchlr, llclhr, llhhhr, llhhlr, llhlhr,
nhhr, nhlr, nlhr, ohhr, ohlr, olhr, xhhr, xhlr, xlhr
[1] IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
[2] IBM z/Architecture Reference Summary, SA22-7871-11,
https://www.ibm.com/support/pages/sites/default/files/2022-09/SA22-7871-11.pdf
Jens Remus [Thu, 23 Nov 2023 14:46:46 +0000 (15:46 +0100)]
s390: Align optional operand definition to specs
The IBM z/Architecture Principle of Operation [1] specifies the last
operand(s) of some (extended) mnemonics to be optional. Align the
mnemonic definitions in the opcode table according to specification.
This changes the last operand of the following (extended) mnemonics to
be optional:
risbg, risbgz, risbgn, risbgnz, risbhg, risblg, rnsbg, rosbg, rxsbg
Note that efpc and sfpc actually have only one operand, but had
erroneously been defined to have two. For backwards compatibility the
wrong RR register format must be retained. Since the superfluous second
operand is defined as optional the instruction can still be coded as
specified.
[1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16,
https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf
opcodes/
* s390-opc.txt: Align optional operand definition to
specification.
testsuite/
* zarch-z10.s: Add test cases for risbg, risbgz, rnsbg, rosbg,
and rxsbg.
* zarch-z10.d: Likewise.
* zarch-z196.s: Add test cases for risbhg and risblg.
* zarch-z196.d: Likewise.
* zarch-zEC12.s: Add test cases for risbgn and risbgnz.
* zarch-zEC12.d: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Jens Remus [Thu, 23 Nov 2023 14:45:42 +0000 (15:45 +0100)]
s390: Make operand table indices relative to each other
This is a purely mechanical change. It allows subsequent insertions into
the operands table without having to renumber all operand indices.
The only differences in the resulting ELF object are in the .debug_info
section. This has been confirmed by diffing the following xxd and readelf
output:
Jens Remus [Thu, 23 Nov 2023 14:44:41 +0000 (15:44 +0100)]
s390: Add brasl edge test cases from ESA to z/Architecture
The ESA opcode test cases for IBM z900 contain a few edge cases. They
exercise the brasl mnemonic with its largest allowed negative and
positive offsets. Linux on zSeries in ESA mode executes in 31-bit
addressing mode. Therefore the ESA test cases are assembled with -m31.
In 31-bit addressing mode the address computation using those large
offsets wraps, which is correctly reflected in the disassembly.
Linux on Z in z/Architecture mode executes in 64-bit addressing mode.
Therefore the z/Architecture (zarch) test cases are assembled with -m64.
In 64-bit addressing mode the address computation using those large
offsets does not necessarily wrap.
gas/
* testsuite/gas/s390/zarch-z900.s: Add brasl tests from ESA that
exercise edge cases.
* testsuite/gas/s390/zarch-z900.d: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Jens Remus [Thu, 23 Nov 2023 14:43:36 +0000 (15:43 +0100)]
s390: Position independent verification of relative addressing
Opcode test cases for z/Architecture instructions that use relative
addressing contained hardcoded offsets in the test verification
patterns. Inserting or reordering of instructions into those test cases
therefore required updating of those hardcoded offsets.
Use regular expressions with backreferences to verify results of test
cases containing instructions with relative addressing. This makes the
verification position independent.
gas/
* testsuite/gas/s390/esa-g5.d: Make opcode test verification
pattern position independent where possible.
* testsuite/gas/s390/esa-z900.d: Likewise.
* testsuite/gas/s390/zarch-z900.d: Likewise.
* testsuite/gas/s390/zarch-z10.d: Likewise.
* testsuite/gas/s390/zarch-z196.d: Likewise.
* testsuite/gas/s390/zarch-zEC12.d: Likewise.
Signed-off-by: Jens Remus <jremus@linux.ibm.com> Reviewed-by: Andreas Krebbel <krebbel@linux.ibm.com>
Tom Tromey [Wed, 22 Nov 2023 13:54:40 +0000 (06:54 -0700)]
Fix build with GCC 7.5
A recent change to 'struct field' caused a build failure with GCC
7.5.0, as reported by Tom de Vries:
/data/vries/gdb/src/gdb/gdbtypes.h:721:51: error:
‘field::m_accessibility’ is too small to hold all values of ‘enum
class accessibility’ [-Werror]
ENUM_BITFIELD (accessibility) m_accessibility : 2;
^
Mark Wielaard pointed out that this was a GCC bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
This patch works around the bug by changing several members not to be
bitfields. It reduces the size of the enum's underlying type,
instead.
I also changed m_bitsize to no longer be a bitfield -- that was done
for packing reasons in ancient times, but with m_accessibility not
being a bitfield, this no longer matters.
I removed fn_field::dummy. In earlier times it was somewhat normal in
gdb to have these dummy fields to keep track of any available padding.
However, since the advent of "ptype/o", there doesn't seem to be any
need for this.
This patch does not change the size of struct field, fn_field, or
decl_field on 64-bit hosts.
Jin Ma [Sat, 18 Nov 2023 07:08:59 +0000 (15:08 +0800)]
RISC-V: Add vector permutation instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds permutation instructions for the "XTheadVector"
extension. The 'th' prefix and the "XTheadVector" extension
are documented in a PR for the RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:08:32 +0000 (15:08 +0800)]
RISC-V: Add vector mask instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds mask instructions for the "XTheadVector"
extension. The 'th' prefix and the "XTheadVector" extension
are documented in a PR for the RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:08:12 +0000 (15:08 +0800)]
RISC-V: Add reductions instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds reductions instructions for the "XTheadVector"
extension. The 'th' prefix and the "XTheadVector" extension
are documented in a PR for the RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:07:39 +0000 (15:07 +0800)]
RISC-V: Add floating-point arithmetic instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds floating-point arithmetic instructions for the
"XTheadVector" extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:07:20 +0000 (15:07 +0800)]
RISC-V: Add fixed-point arithmetic instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds fixed-point arithmetic instructions for the
"XTheadVector" extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:07:00 +0000 (15:07 +0800)]
RISC-V: Add integer arithmetic instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds integer arithmetic instructions for the
"XTheadVector" extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:06:31 +0000 (15:06 +0800)]
RISC-V: Add sub-extension XTheadZvamo for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds the sub-extension "XTheadZvamo" for the
"XTheadVector" extension, and it provides AMO instructions
for T-Head VECTOR vendor extension. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:05:31 +0000 (15:05 +0800)]
RISC-V: Add load/store segment instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore it
makes sense to group them into smaller chunks in form of vendor
extensions.
This patch adds provides load/store segment instructions for T-Head VECTOR
vendor extension, which same as the "Zvlsseg" extension in RVI 0.71 vector
extension, but belongs to the "XTheadVector" extension. The 'th' prefix
and the "XTheadVector" extension are documented in a PR for the
RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:04:50 +0000 (15:04 +0800)]
RISC-V: Add load/store instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions. Therefore
it makes sense to group them into smaller chunks in form of
vendor extensions.
This patch adds load/store instructions for the "XTheadVector"
extension. The 'th' prefix and the "XTheadVector" extension are
documented in a PR for the RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 07:04:01 +0000 (15:04 +0800)]
RISC-V: Add configuration-setting instructions for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds configuration-setting instructions for the "XTheadVector"
extension. The 'th' prefix and the "XTheadVector" extension are documented
in a PR for the RISC-V toolchain conventions ([1]).
Jin Ma [Sat, 18 Nov 2023 06:58:25 +0000 (14:58 +0800)]
RISC-V: Add CSRs for T-Head VECTOR vendor extension
T-Head has a range of vendor-specific instructions.
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the CSRs for XTheadVector. Because of the
conflict between encoding and teh 'V' extension, it is implemented
by alias. The 'th' prefix and the "XTheadVector" extension are
documented in a PR for the RISC-V toolchain conventions ([1]).
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
gas/ChangeLog:
* config/tc-riscv.c (enum riscv_csr_class): Add the class for
the CSRs of the "XTheadVector" extension.
(riscv_csr_address): Likewise.
* testsuite/gas/riscv/x-thead-vector-csr-warn.d: New test.
* testsuite/gas/riscv/x-thead-vector-csr-warn.l: New test.
* testsuite/gas/riscv/x-thead-vector-csr.d: New test.
* testsuite/gas/riscv/x-thead-vector-csr.s: New test.
Jin Ma [Sat, 18 Nov 2023 06:53:08 +0000 (14:53 +0800)]
RISC-V: Add T-Head VECTOR vendor extension.
T-Head has a range of vendor-specific instructions ([2]).
Therefore it makes sense to group them into smaller chunks
in form of vendor extensions.
This patch adds the "XTheadVector" extension, a collection of
T-Head-specific vector instructions. The 'th' prefix and the
"XTheadVector" extension are documented in a PR for the RISC-V
toolchain conventions ([1]).
Here are some things that need to be explained:
The "XTheadVector" extension is not a custom-extension, but
a non-standard non-conforming extension. The encoding space
of the "TheadVector" instructions overlaps with those of
the 'V' extension. This encoding space conflict is not on
purpose, but the result of issues in the past that have
been resolved since. Therefore, the "XTheadVector" extension
and the 'V' extension are in conflict.
Co-developed-by: Lifang Xia <lifang_xia@linux.alibaba.com> Co-developed-by: Christoph Müllner <christoph.muellner@vrull.eu>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_parse_check_conflicts): The
"XTheadVector" extension and the 'V' extension are in conflict.
(riscv_multi_subset_supports): Likewise..
(riscv_multi_subset_supports_ext): Likewise.
gas/ChangeLog:
* doc/c-riscv.texi:
* testsuite/gas/riscv/x-thead-vector-fail.d: New test.
* testsuite/gas/riscv/x-thead-vector-fail.l: New test.
* testsuite/gas/riscv/x-thead-vector.s: New test.
In AIX, while we followed the child process and detach on fork was on we hit thr!= NULL assertion failure.
The reason for the same was GDB core trying to switch to a child thread with tid not set that does not
exist, since child's ptid was changed to ptid_t (pid, 0, tid) in sync_threadlists() as it was threaded.
The way this happened was when a new child process is born, its object file will be loaded, calling the new_objfile ()
in aix-thread.c file from clone_program_space, which is
called from within follow_fork_inferior. Therefore it end ups syncing threadlists via pd_update ().
This patch is a fix for the same where pd_update () is called in the wait () or in update_thread_list() hook only.
Tom de Vries [Wed, 22 Nov 2023 18:07:47 +0000 (19:07 +0100)]
[gdb/tui] Fix resizing of terminal to 1 or 2 lines
When starting TUI in a terminal with 3 lines:
...
$ echo $LINES
3
$ gdb -q -tui
...
and resizing the terminal to 2 lines we run into a segfault.
The problem is that for the source window:
- the minimum height is 3 (the default), but
- the maximum height is only 2 because there are only 2 lines.
This discrepancy eventually leads to a call to newwin in make_window with:
...
(gdb) p height
$1 = 3
(gdb) p width
$2 = 56
(gdb) p y
$3 = -1
(gdb) p x
$4 = 0
...
which results in a nullptr.
This violates the assumption here in tui_apply_current_layout:
....
/* Get the new list of currently visible windows. */
std::vector<tui_win_info *> new_tui_windows;
applied_layout->get_windows (&new_tui_windows);
...
that get_windows only returns visible windows, which leads to tui_windows
holding a dangling pointer, which results in the segfault.
Fix this by:
- making sure get_windows only returns visible windows, and
- detecting the situation and dropping windows from the layout if
there's no room for them.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31044
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
Tom de Vries [Wed, 22 Nov 2023 18:07:47 +0000 (19:07 +0100)]
[gdb/tui] Allow command window of 1 or 2 lines
When starting TUI in a terminal with 2 lines (likewise with 1 line):
...
$ echo $LINES
2
$ gdb -q -tui
...
we run into this assert in tui_apply_current_layout:
...
/* This should always be made visible by a layout. */
gdb_assert (TUI_CMD_WIN != nullptr);
...
The problem is that for the command window:
- the minimum height is 3 (the default), but
- the maximum height is only 2 because there are only 2 lines.
This discrepancy eventually leads to a call to newwin in make_window with:
...
(gdb) p height
$1 = 3
(gdb) p width
$2 = 66
(gdb) p y
$3 = -1
(gdb) p x
$4 = 0
(gdb)
...
which results in a nullptr, which eventually triggers the assert.
The easiest way to fix this is to change the minimum height of the command
window to 1. However, that would also change behaviour for the case that the
screen size is 3 lines or more. For instance, in gdb.tui/winheight.exp the
number of lines in the terminal is 24, and the test-case checks that the user
cannot increase the source window height to the point that the command window
height would be less than 3.
Fix this by calculating the minimum height of the command window as follows:
- the default (3) if max_height () allows it, and
- max_height () otherwise.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR tui/31044
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31044
I ran into a failure in test-case gdb.python/py-missing-debug.exp with python
3.6, which was fixed by commit 7db795bc67a ("gdb/python: remove use of
str.isascii()").
However, I subsequently ran into a failure with python 3.11:
...
(gdb) PASS: $exp: initial checks: debug info no longer found
source py-missing-debug.py^M
Traceback (most recent call last):^M
File "py-missing-debug.py", line 17, in <module>^M
from gdb.missing_debug import MissingDebugHandler^M
File "missing_debug.py", line 21, in <module>^M
from curses.ascii import isascii, isalnum^M
File "/usr/lib64/python3.11/_import_failed/curses.py", line 16, in <module>^M
raise ImportError(f"""Module '{failed_name}' is not installed.^M
ImportError: Module 'curses' is not installed.^M
Use:^M
sudo zypper install python311-curses^M
to install it.^M
(gdb) FAIL: $exp: source python script
...
Apparently I have the curses module installed for 3.6, but not 3.11.
I could just install it, but the test-case worked fine with 3.11 before commit 7db795bc67a.
Fix this by only using the curses module when necessary, for python <= 3.7.
Tested on x86_64-linux, with both python 3.6 and 3.11.
we can cleanup how the help text is generated in monitor_show_help.
This doesn't change the output that the user will see -- it just folds
multiple monitor_output calls into one.
There should be no user visible change after this commit.
Tom Tromey [Fri, 27 Oct 2023 16:58:00 +0000 (10:58 -0600)]
Simplify C++ type-printing
The C++ type-printing code had its own variant of the accessibility
enum. This patch removes this and changes the code to use the new one
from gdbtypes.h.
This patch also changes the C++ code to recognize the default
accessibility of a class. This makes ptype a bit more C++-like, and
lets us remove a chunk of questionable code.
Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Keith Seitz <keiths@redhat.com>
Tom Tromey [Fri, 27 Oct 2023 16:51:50 +0000 (10:51 -0600)]
Use enum accessibility in types and member functions
This changes nested types and member functions to use the new
'accessibility' enum, rather than separate private/protected flags.
This is done for consistency, but it also lets us simplify some other
code in the next patch.
Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Keith Seitz <keiths@redhat.com>
Tom Tromey [Thu, 21 Sep 2023 16:21:04 +0000 (10:21 -0600)]
Remove byte vectors from cplus_struct_type
This removes some byte vectors from cplus_struct_type, moving the
information into bitfields in holes in struct field.
A new 'enum accessibility' is added to hold some of this information.
A similar enum is removed from c-varobj.c.
Note that the stabs reader treats "ignored" as an accessibility.
However, the stabs texinfo documents this as a public field that is
optimized out -- unfortunately nobody has updated the stabs reader to
use the better value-based optimized-out machinery. I looked and
apparently gcc never emitted this visibility value, so whatever
compiler generated this stab is unknown. I left a comment in
gdbtypes.h to this effect.
Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Keith Seitz <keiths@redhat.com>
Tom Tromey [Thu, 21 Sep 2023 16:49:57 +0000 (10:49 -0600)]
Print field accessibility inline
This changes recursive_dump_type to print field accessibility
information "inline". This is clearer and preserves the information
when the byte vectors are removed.
Acked-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Keith Seitz <keiths@redhat.com>
bpf: Fixed register parsing disambiguating with possible symbol.
This changes parse_bpf_register to detect possible symbols that start with valid
register name, however due some following characters are not.
Also changed the regs-for-symbols-pseudo.s, adding some entries that
should not error if parser is properly detecting the symbol.
Simon Marchi [Tue, 21 Nov 2023 16:42:41 +0000 (11:42 -0500)]
gdb: fix build of darwin-nat.c
Patch 743877128 ("gdb: remove regcache's address space") changed the
signature of darwin_nat_target::cancel_breakpoint, but missing updating
the class declaration, resulting in:
CXX darwin-nat.o
/Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1154:20: error: out-of-line definition of 'cancel_breakpoint' does not match any declaration in 'darwin_nat_target'
darwin_nat_target::cancel_breakpoint (inferior *inf, ptid_t ptid)
^~~~~~~~~~~~~~~~~
/Users/smarchi/src/binutils-gdb/gdb/darwin-nat.c:1290:9: error: too many arguments to function call, expected single argument 'ptid', have 2 arguments
ptid_t (inf->pid, 0, thread->gdb_port)))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/smarchi/src/binutils-gdb/gdb/darwin-nat.h:129:7: note: 'cancel_breakpoint' declared here
int cancel_breakpoint (ptid_t ptid);
^
Tom Tromey [Tue, 7 Nov 2023 16:16:48 +0000 (09:16 -0700)]
Refactor DAP queue handling
A couple of spots in the DAP code use the same workaround for the
absence of queue.SimpleQueue before Python 3.6. This patch
consolidates these into a single spot.
Tom de Vries [Tue, 21 Nov 2023 12:57:19 +0000 (13:57 +0100)]
[gdb/tdep] Handle memory error in s390_linux_get_syscall_number
In s390_linux_get_syscall_number, we use read_memory_unsigned_integer, which
can throw a memory error.
According to the function comment though, it should return -1 on error:
...
/* Retrieve the syscall number at a ptrace syscall-stop. Return -1
upon error. */
...
Catch the memory error by using safe_read_memory_unsigned_integer instead,
similar to how that was fixed for arm in commit eb42bb14895 ("[gdb/tdep] Fix
catching syscall execve exit for arm").
Tom de Vries [Tue, 21 Nov 2023 12:15:29 +0000 (13:15 +0100)]
[gdb/testsuite] Fix spurious FAILs with examine-backward.exp, again
Commit 59a561480d5 ("Fix spurious FAILs with examine-backward.exp") describes
the problem that:
...
The test case examine-backward.exp issues the command "x/-s" after the end
of the first string in TestStrings, but without making sure that this
string is preceded by a string terminator. Thus GDB may spuriously print
some random characters from before that string, and then the test fails.
...
The commit fixes the problem by adding a Barrier variable before the TestStrings
variable:
...
+const char Barrier[] = { 0x0 };
const char TestStrings[] = {
...
There is however no guarantee that Barrier is placed immediately before
TestStrings.
Before recent commit 169fe7ab54b ("Change gdb.base/examine-backwards.exp for
AIX.") on x86_64-linux, I see:
... 0000000000400660 R Barrier 0000000000400680 R TestStrings
...
So while the Barrier variable is the first before the TestStrings variable,
it's not immediately preceding TestStrings.
Fix this reliably by adding the zero in the array itself:
...
char TestStringsBase[] = {
0x0,
...
};
char *TestStrings = &TestStringsBase[1];
...
and do likewise for TestStringsH and TestStringsW.
Lancelot Six [Fri, 13 Oct 2023 12:45:58 +0000 (12:45 +0000)]
gdb/disasm.h: Mark callbacks noexcept unconditionally
Given that C++17 is now a requirement for GDB, update gdb/disasm.h to
define callback function types noexcept unconditionally. The pre-C++17
configuration is not supported anymore.
Change-Id: I0a38e22b7912c70a11425363a991f0b01614343e Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Lancelot Six [Fri, 13 Oct 2023 10:23:59 +0000 (10:23 +0000)]
gdbsupport: Remove gdb::string_view
Now that all places using gdb::string_view have been updated to use
std::string_view, this patch drops the gdb::string_view implementation
and the tests which came with it.
As this drops the unittests/string_view-selftests.c, this also
implicitly solves PR build/23676, as pointed-out by Tom Tromey.
Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23676
Lancelot Six [Fri, 13 Oct 2023 10:54:46 +0000 (10:54 +0000)]
gdb: Remove uses of gdb::to_string (const std::string_view &)
This patch removes all uses of to_string(const std::string_view&) and
use the std::string ctor or implicit conversion from std::string_view to
std::string instead.
A later patch will remove this gdb::to_string while removing
gdbsupport/gdb_string_view.h.
Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Lancelot Six [Fri, 13 Oct 2023 10:17:02 +0000 (10:17 +0000)]
gdb: Use std::string_view instead of gdb::string_view
Given that GDB now requires a C++17, replace all uses of
gdb::string_view with std::string_view.
This change has mostly been done automatically:
- gdb::string_view -> std::string_view
- #include "gdbsupport/gdb_string_view.h" -> #include <string_view>
One things which got brought up during review is that gdb::stging_view
does support being built from "nullptr" while std::sting_view does not.
Two places are manually adjusted to account for this difference:
gdb/tui/tui-io.c:tui_getc_1 and
gdbsupport/format.h:format_piece::format_piece.
The above automatic change transformed
"gdb::to_string (const gdb::string_view &)" into
"gdb::to_string (const std::string_view &)". The various direct users
of this function are now explicitly including
"gdbsupport/gdb_string_view.h". A later patch will remove the users of
gdb::to_string.
The implementation and tests of gdb::string_view are unchanged, they will
be removed in a following patch.
Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Lancelot Six [Fri, 13 Oct 2023 09:55:19 +0000 (09:55 +0000)]
gdbsupport: remove gdb::optional
The previous patch migrated all the uses of gdb::optional to use
std::optional instead, so gdb::optional can be removed entirely
as well as the self-tests which came with it.
Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Lancelot Six [Fri, 13 Oct 2023 09:27:48 +0000 (09:27 +0000)]
gdb: Replace gdb::optional with std::optional
Since GDB now requires C++17, we don't need the internally maintained
gdb::optional implementation. This patch does the following replacing:
- gdb::optional -> std::optional
- gdb::in_place -> std::in_place
- #include "gdbsupport/gdb_optional.h" -> #include <optional>
This change has mostly been done automatically. One exception is
gdbsupport/thread-pool.* which did not use the gdb:: prefix as it
already lives in the gdb namespace.
Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9 Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net>
Lancelot Six [Thu, 14 Sep 2023 11:13:24 +0000 (11:13 +0000)]
gdb: Use C++17's std::make_unique instead of gdb::make_unique
gdb::make_unique is a wrapper around std::make_unique when compiled with
C++17. Now that C++17 is required, use std::make_unique directly in the
codebase, and remove gdb::make_unique.
Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab Approved-By: Tom Tromey <tom@tromey.com> Approved-By: Pedro Alves <pedro@palves.net
Tom de Vries [Tue, 21 Nov 2023 10:44:07 +0000 (11:44 +0100)]
[gdb/tdep] Fix catching syscall execve exit for arm
When running test-case gdb.base/catch-syscall.exp on a pinebook (64-bit
aarch64 kernel, 32-bit userland) I run into:
...
(gdb) PASS: $exp: execve: syscall(s) execve appears in 'info breakpoints'
continue^M
Continuing.^M
^M
Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from \
/lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve
continue^M
Continuing.^M
process 32392 is executing new program: catch-syscall^M
Cannot access memory at address 0xf77c6a7c^M
(gdb) FAIL: $exp: execve: syscall execve has returned
...
The memory error is thrown by arm_linux_get_syscall_number, when doing:
...
/* PC gets incremented before the syscall-stop, so read the
previous instruction. */
unsigned long this_instr =
read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
...
The reason for the error is that we're stopped at the syscall exit of syscall
execve, and the pc is at the first insn of the new exec, which also happens to
be the first insn in the code segment, so consequently we cannot read the
previous insn.
Fix this by detecting the situation by looking at the register state, similar
to what is done in aarch64_linux_get_syscall_number.
Furthermore, catch the memory error by using safe_read_memory_unsigned_integer
and return -1 instead, matching the documented behaviour of
arm_linux_get_syscall_number.
Finally, rather than using a hardcoded constant 11, introduce an ad-hoc
arm_sys_execve.
Nick Clifton [Tue, 21 Nov 2023 09:26:19 +0000 (09:26 +0000)]
Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
PR 31067
* linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton.
* ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave.
In AIX, we are not able to see the message of a signal recieved if a debugee recieves a signal.
This is a patch to fix the signal handling done incorrectly in AIX.
We remove the status that represent program recieving a signal and allow host_status_to_waitstatus to
handle it for us.
This binary causes a segfault in GDB. GDB is trying to write the .dynamic
section into memory allocated on the stack with alloca(). However, the
allocation silently fails and the subsequent access to the memory is
causing the segfault. (On my node at least.)
Stack allocation is a bad idea for something of variable size that GDB has
no control over. So I changed the code to heap allocation.
In addition, I changed the type of sect_size to the type that bfd actually
returns.
There should be no user visible change after this.
Tom Tromey [Mon, 20 Nov 2023 16:31:32 +0000 (09:31 -0700)]
Restore .gdb_index v9 display in readelf
An earlier patch (commit b05efa39 "readelf..debug-dump=loc displays
bogus base addresses") inadvertently removed support for displaying
.gdb_index v9 sections.
This patch corrects the oversight. I tested this by using readelf on
an appropriate file.
Carl Love [Mon, 20 Nov 2023 16:13:22 +0000 (11:13 -0500)]
PowerPC: Fix test gdb.ada/finish-large.exp
Function Create_large returns a large data structure. On PowerPC, register
r3 contains the address of where the data structure to be returned is to
be stored. However, on exit the ABI does not guarantee that r3 has not
been changed. The GDB finish command prints the return value of the
function at the end of the function. GDB needs to use the
DW_TAG_call_site information to determine the value of r3 on entry to
the function to correctly print the return value at the end of the
function. The test must be compiled with -fvar-tracking for the
DW_TAG_call_site information to be included in the executable file.
This patch adds the -fvar-tracking option to the compile line if the
option is supported.
The patch fixes the one regression error for the test on PowerPC.
The patch has been tested on Power 10 and X86-64 with no regressions.
Nick Alcock [Tue, 7 Nov 2023 21:11:18 +0000 (21:11 +0000)]
libctf: adding CU mappings should be idempotent
When CTF finds conflicting types, it usually shoves each definition
into a CTF dictionary named after the compilation unit.
The intent of the obscure "cu-mapped link" feature is to allow you to
implement custom linkers that shove the definitions into other, more
coarse-grained units (say, one per kernel module, even if a module consists
of more than one compilation unit): conflicting types within one of these
larger components are hidden from name lookup so you can only look up (an
arbitrary one of) them by name, but can still be found by chasing type graph
links and are still fully deduplicated.
You do this by calling
ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly,
with different "CU name"s: the ctf_link() following that will put all
conflicting types found in "CU name"s sharing a "bigger lump name" into a
child dict in an archive member named "bigger lump name".
So it's clear enough what happens if you call it repeatedly with the same
"bigger lump name" more than once, because that's the whole point of it: but
what if you call it with the same "CU name" repeatedly?
This is meant to be the same as just doing the second of these, as if the
first was never called. Alas, this isn't what happens, and what you get is
instead a bit of an inconsistent mess: more or less, the first takes
precedence, which is the exact opposite of what we wanted.
Fix this to work the right way round.
(I plan to add support for CU-mapped links to GNU ld, mainly so that we can
properly *test* this machinery.)
libctf/ChangeLog:
* ctf-link.c (ctf_create_per_cu): Note the behaviour of
repeatedly adding FROMs.
(ctf_link_add_cu_mapping): Implement that behavour.
gdb: fix reread_symbols when an objfile has target: prefix
In this commit I update reopen_exec_file to correctly handle
executables with a target: prefix. Before this commit we used the
system 'stat' call, which obviously isn't going to work for files with
a target: prefix (files located on a possibly remote target machine).
By switching to bfd_stat we will use remote fileio to stat the remote
files, which means we should now correctly detect changes in a remote
executable.
The program_space::ebfd_mtime variable, with which we compare the
result of bfd_stat is set with a call to bfd_get_mtime, which in turn
calls bfd_stat, so comparing to the result of calling bfd_stat makes
sense (I think).
As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
will always return the time at which the BFD was created. As a result
comparing the results will always show the file having changed.
I don't believe that GDB can set the main executable to an in-memory
BFD object, so, in this commit, I simply assert that the executable is
not in-memory. If this ever changes then we would need to decide how
to handle this case -- always reload, or never reload. The assert
doesn't appear to trigger for our current test suite.
Andrew Burgess [Tue, 24 Oct 2023 16:54:51 +0000 (17:54 +0100)]
gdb: move all bfd_cache_close_all calls in gdb_bfd.c
In the following commit I ran into a problem. The next commit aims to
improve GDB's handling of the main executable being a file on a remote
target (i.e. one with a 'target:' prefix).
To do this I have replaced a system 'stat' call with a bfd_stat call.
However, doing this caused a regression in gdb.base/attach.exp.
The problem is that the bfd library caches open FILE* handles for bfd
objects that it has accessed, which is great for short-lived, non
interactive programs (e.g. the assembler, or objcopy, etc), however,
for GDB this caching causes us a problem.
If we open the main executable as a bfd then the bfd library will
cache the open FILE*. If some time passes, maybe just sat at the GDB
prompt, or with the inferior running, and then later we use bfd_stat
to check if the underlying, on-disk file has changed, then the bfd
library will actually use fstat on the underlying file descriptor.
This is of course slightly different than using system stat on with
the on-disk file name.
If the on-disk file has changed then system stat will give results for
the current on-disk file. But, if the bfd cache is still holding open
the file descriptor for the original on-disk file (from before the
change) then fstat will return a result based on the original file,
and so show no change as having happened.
This is a known problem in GDB, and so far this has been solved by
scattering bfd_cache_close_all() calls throughout GDB. But, as I
said, in the next commit I've made a change and run into a
problem (gdb.base/attach.exp) where we are apparently missing a
bfd_cache_close_all() call.
Now I could solve this problem by adding a bfd_cache_close_all() call
before the bfd_stat call that I plan to add in the next commit, that
would for sure solve the problem, but feels a little crude.
Better I think would be to track down where the bfd is being opened
and add a corresponding bfd_cache_close_all() call elsewhere in GDB
once we've finished doing whatever it is that caused us to open the
bfd in the first place.
This second solution felt like the better choice, so I tracked the
problem down to elf_locate_base and fixed that. But that just exposed
another problem in gdb_bfd_map_section which was also re-opening the
bfd, so I fixed this (with another bfd_cache_close_all() call), and
that exposed another issue in gdbarch_lookup_osabi... and at this
point I wondered if I was approaching this problem the wrong way...
.... And so, I wonder, is there a _better_ way to handle these
bfd_cache_close_all() calls?
I see two problems with the current approach:
1. It's fragile. Folk aren't always aware that they need to clear
the bfd cache, and this feels like something that is easy to
overlook in review. So adding new code to GDB can innocently touch
a bfd, which populates the cache, which will then be a bug that can
lie hidden until an on-disk file just happens to change at the wrong
time ... and GDB fails to spot the change. Additionally,
2. It's in efficient. The caching is intended to stop the bfd
library from continually having to re-open the on-disk file. If we
have a function that touches a bfd then often that function is the
obvious place to call bfd_cache_close_all. But if a single GDB
command calls multiple functions, each of which touch the bfd, then
we will end up opening and closing the same on-disk file multiple
times. It feels like we would be better postponing the
bfd_cache_close_all call until some later point, then we can benefit
from the bfd cache.
So, in this commit I propose a new approach. We now clear the bfd
cache in two places:
(a) Just before we display a GDB prompt. We display a prompt after
completing a command, and GDB is about to enter an idle state
waiting for further input from the user (or in async mode, for an
inferior event). If while we are in this idle state the user
changes the on-disk file(s) then we would like GDB to notice this
the next time it leaves its idle state, e.g. the next time the user
executes a command, or when an inferior event arrives,
(b) When we resume the inferior. In synchronous mode, resuming the
inferior is another time when GDB is blocked and sitting idle, but
in this case we don't display a prompt. As with (a) above, when an
inferior event arrives we want GDB to notice any changes to on-disk
files.
It turns out that there are existing observers for both of these
cases (before_prompt and target_resumed respectively), so my initial
thought was that I should attach to these observers in gdb_bfd.c, and
in both cases call bfd_cache_close_all().
And this does indeed solve the gdb.base/attach.exp problem that I see
with the following commit.
However, I see a problem with this solution.
Both of the observers I'm using are exposed through the Python API as
events that a user can hook into. The user can potentially run any
GDB command (using gdb.execute), so Python code might end up causing
some bfds to be reopened, and inserted into the cache.
To solve this one solution would be to add a bfd_cache_close_all()
call into gdbpy_enter::~gdbpy_enter(). Unfortunately, there's no
similar enter/exit object for Guile, though right now Guile doesn't
offer the same event API, so maybe we could just ignore that
problem... but this doesn't feel great.
So instead, I think a better solution might be to not use observers
for the bfd_cache_close_all() calls. Instead, I'll call
bfd_cache_close_all() directly from core GDB after we've notified the
before_prompt and target_resumed observers, this was we can be sure
that the cache is cleared after the observers have run, and before GDB
enters an idle state.
This commit also removes all of the other bfd_cache_close_all() calls
from GDB. My claim is that these are no longer needed.
The previous commit introduced some local variables to make some if
statements simpler. This commit uses them more liberally throughout the
process_event_stop_test in order to simplify the function a little more.
No functional changes are expected.
gdb/record: print frame information when exiting a recursive call
Currently, when GDB is reverse stepping out of a function into the same
function due to a recursive call, it doesn't print frame information, as
reported by PR record/29178. This happens because when the inferior
leaves the current frame, GDB decides to refresh the step information,
clobbering the original step_frame_id, making it impossible to figure
out later on that the frame has been changed.
This commit changes GDB so that, if we notice we're in this exact
situation, we won't refresh the step information.
Because of implementation details, this change can cause some debug
information to be read when it normally wouldn't before, which showed up
as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
isn't a problem, the test was changed to allow for the new output.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 Approved-By: Tom Tromey <tom@tromey.com>
Jose E. Marchesi [Sat, 18 Nov 2023 17:12:44 +0000 (18:12 +0100)]
gas: bpf: do not allow referring to register names as symbols in operands
2023-11-18 Jose E. Marchesi <jemarch@gnu.org>
* config/tc-bpf.c (parse_bpf_register): Move before
bpf_parse_name.
(bpf_parse_name): Do not allow using symbols that are also
register names as operands in pseudo-c syntax.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.d: New file.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.s: Likewise.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.l: Likewise.
* doc/c-bpf.texi (BPF Registers): Document that it is not possible
to refer to register names as symbols in instruction operands.
David Faust [Thu, 16 Nov 2023 17:35:03 +0000 (09:35 -0800)]
bpf: avoid creating wrong symbols while parsing
To support the "pseudo-C" asm dialect in BPF, the BPF parser must often
attempt multiple different templates for a single instruction. In some
cases this can cause the parser to incorrectly parse part of the
instruction opcode as an expression, which leads to the creation of a
new undefined symbol.
Once the parser recognizes the error, the expression is discarded and it
tries again with a new instruction template. However, symbols created
during the process are added to the symbol table and are not removed
even if the expression is discarded.
This is a problem for BPF: generally the assembled object will be loaded
directly to the Linux kernel, without being linked. These erroneous
parser-created symbols are rejected by the kernel BPF loader, and the
entire object is refused.
This patch remedies the issue by tentatively creating symbols while
parsing instruction operands, and storing them in a temporary list
rather than immediately inserting them into the symbol table. Later,
after the parser is sure that it has correctly parsed the instruction,
those symbols are committed to the real symbol table.
This approach is modeled directly after Jan Beulich's patch for RISC-V:
Many thanks to Jan for recognizing the problem as similar, and pointing
me to that patch.
gas/
* config/tc-bpf.c (parsing_insn_operands): New.
(parse_expression): Set it here.
(deferred_sym_rootP, deferred_sym_lastP): New.
(orphan_sym_rootP, orphan_sym_lastP): New.
(bpf_parse_name): New.
(parse_error): Clear deferred symbol list on error.
(md_assemble): Clear parsing_insn_operands. Commit deferred
symbols to symbol table on successful parse.
* config/tc-bpf.h (md_parse_name): Define to...
(bpf_parse_name): ...this. New prototype.
* testsuite/gas/bpf/asm-extra-sym-1.s: New test source.
* testsuite/gas/bpf/asm-extra-sym-1.d: New test.
* testsuite/gas/bpf/bpf.exp: Run new test.
Simon Marchi [Sun, 5 Nov 2023 04:47:26 +0000 (04:47 +0000)]
gdb: remove get_current_regcache
Remove get_current_regcache, inlining the call to get_thread_regcache in
callers. When possible, pass the right thread_info object known from
the local context. Otherwise, fall back to passing `inferior_thread ()`.
This makes the reference to global context bubble up one level, a small
step towards the long term goal of reducing the number of references to
global context (or rather, moving those references as close as possible
to the top of the call tree).
Simon Marchi [Fri, 17 Nov 2023 19:55:58 +0000 (19:55 +0000)]
gdb: remove regcache's address space
While looking at the regcache code, I noticed that the address space
(passed to regcache when constructing it, and available through
regcache::aspace) wasn't relevant for the regcache itself. Callers of
regcache::aspace use that method because it appears to be a convenient
way of getting the address space for a thread, if you already have the
regcache. But there is always another way to get the address space, as
the callers pretty much always know which thread they are dealing with.
The regcache code itself doesn't use the address space.
This patch removes anything related to address_space from the regcache
code, and updates callers to get it from the thread in context. This
removes a bit of unnecessary complexity from the regcache code.
The current get_thread_arch_regcache function gets an address_space for
the given thread using the target_thread_address_space function (which
calls the target_ops::thread_address_space method). This suggest that
there might have been the intention of supporting per-thread address
spaces. But digging through the history, I did not find any such case.
Maybe this method was just added because we needed a way to get an
address space from a ptid (because constructing a regcache required an
address space), and this seemed like the right way to do it, I don't
know.
The only implementations of thread_address_space and
process_stratum_target::thread_address_space and
linux_nat_target::thread_address_space, which essentially just return
the inferior's address space. And thread_address_space is only used in
the current get_thread_arch_regcache, which gets removed. So, I think
that the thread_address_space target method can be removed, and we can
assume that it's fine to use the inferior's address space everywhere.
Callers of regcache::aspace are updated to get the address space from
the relevant inferior, either using some context they already know
about, or in last resort using the current global context.
So, to summarize:
- remove everything in regcache related to address spaces
- in particular, remove get_thread_arch_regcache, and rename
get_thread_arch_aspace_regcache to get_thread_arch_regcache
- remove target_ops::thread_address_space, and
target_thread_address_space
- adjust all users of regcache::aspace to get the address space another
way
Tom Tromey [Fri, 17 Nov 2023 18:04:08 +0000 (11:04 -0700)]
Remove extraneous blocks from dwarf2/read.c:new_symbol
dwarf2/read.c:new_symbol has some extra braces in a couple of 'case's.
These read weirdly to me, and since they aren't necessary, this patch
removes the braces and reindents the bodies. Tested by rebuilding.
Joseph Myers [Fri, 17 Nov 2023 17:04:14 +0000 (17:04 +0000)]
Fix read_ranges for 32-bit long
bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which
doesn't work correctly when long is 32-bit and bfd_vma is 64-bit
(observed as "nm -l" being very slow for mingw64 host; probably causes
issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64).
Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere.
Tom Tromey [Tue, 7 Nov 2023 15:44:44 +0000 (08:44 -0700)]
Implement the notStopped DAP response
DAP specifies that a request can fail with the "notStopped" message if
the inferior is running but the request requires that it first be
stopped.
This patch implements this for gdb. Most requests are assumed to
require a stopped inferior, and the exceptions are noted by a new
'request' parameter.
You may notice that the implementation is a bit racy. I think this is
inherent -- unless the client waits for a stop event before sending a
request, the request may be processed at any time relative to a stop.
Tom Tromey [Mon, 6 Nov 2023 21:29:06 +0000 (14:29 -0700)]
Remove ExecutionInvoker
ExecutionInvoker is no longer really needed, due to the previous DAP
refactoring. This patch removes it in favor of an ordinary function.
One spot (the 'continue' request) could still have used it, but is
more succinctly expressed as a lambda.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Mon, 6 Nov 2023 20:31:17 +0000 (13:31 -0700)]
Automatically run (most) DAP requests in gdb thread
Nearly every DAP request implementation forwards its work to the gdb
thread, using send_gdb_with_response. This patch refactors the
'request' decorator to make this automatic, and to provide some
parameters so that the unusual requests can express their needs as
well.
In a few spots this simplifies the code by removing an unnecessary
helper function. This could be done in more places as well if we
wanted.
The main motivation for this patch is that I thought it would be
helpful for cancellation. I am still working on that, but meanwhile
the parameterization of 'request' makes it easy to handle the
'notStopped' response as well.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Tom Tromey [Fri, 6 Oct 2023 19:40:39 +0000 (13:40 -0600)]
Handle StackFrameFormat in DAP
DAP specifies a StackFrameFormat object that can be used to change how
the "name" part of a stack frame is constructed. While this output
can already be done in a nicer way (and also letting the client choose
the formatting), nevertheless it is in the spec, so I figured I'd
implement it.
While implementing this, I discovered that the current code does not
correctly preserve frame IDs across requests. I rewrote frame
iteration to preserve this, and it turned out to be simpler to combine
these patches.
The AMD_DBGAPI_SCOPED_DEBUG_START_END macro in gdb/amd-dbgapi-target.c
is incorrectly controlled by "set debug infrun", while it should be
controlled by "set debug amd-dbgapi" instead. This commit fixes it.
Jan Beulich [Fri, 17 Nov 2023 10:24:12 +0000 (11:24 +0100)]
x86: improve a few diagnostics
PR gas/31043
"unsupported instruction ..." can mean about anything, and can also be
mistaken to mean something that isn't meant. Replace most of its uses by
more specific diagnostics,
While there also take the opportunity and purge the no longer used
invalid_register_operand enumerator.
Jan Beulich [Fri, 17 Nov 2023 10:23:20 +0000 (11:23 +0100)]
x86: CPU-qualify {disp16} / {disp32}
{disp16} is invalid to use in 64-bit mode, while {disp32} is invalid to
use on pre-386 CPUs. The latter, also affecting other (real) prefixes,
further requires that like for insns we fully check the CPU flags; till
now only Cpu64/CpuNo64 were taken into consideration.
ELF-only functions don't need to be built when dealing with a non-ELF
target. md_section_align() also doesn't need to be a function when
dealing with non-AOUT targets. Similarly tc_fix_adjustable() can be a
simple macro when building non-ELF targets.
Furthermore x86_elf_abi is already used in ELF-only code sections, with
one exception. By adjusting that, the otherwise bogusly named variable
can also be confined to just ELF builds.
Jan Beulich [Fri, 17 Nov 2023 10:20:25 +0000 (11:20 +0100)]
x86: fold conditionals in check_long_reg()
Simplify the code follow ing what check_{,q}word_reg() already do. This
the also eliminates a stale comment talking about a warning when an
error is raised. While there, correct a similarly stale comment in
check_qword_reg() while there.
Jan Beulich [Fri, 17 Nov 2023 10:20:06 +0000 (11:20 +0100)]
x86-64: extend expected-size check in check_qword_reg()
Due to a missing check "crc32q %al, %rax" was wrongly translated to the
encoding of "crc32q %rax, %rax", rather than being rejected as invalid.
(The mnemonic suffix describes the source operand, not the destination
one.)
Note that check_{word,long}_reg() do not (currently) appear to require
similar amending, as there are no insn templates permitting an L or W
suffix and having an operand which allows for Reg8 and Reg64, but
neither Reg16 nor Reg32.
Previously the condition prevented shared objects from being relaxed.
To remove the limitation, we need to update program header size and
.eh_frame_hdr size before relaxation.
projects / thirdparty / binutils-gdb.git / log
