Simon Marchi [Tue, 26 Nov 2024 03:16:48 +0000 (22:16 -0500)]
gdbserver: use `gdb::unordered_map`
Replace the few uses of `std::unordered_map` with `gdb::unordered_map`.
The only one of these that is likely to ever see a lot of elements is
probably `process_info::m_ptid_thread_map`. It was added precisely to
improve performance when there are a lot of threads. So using
`gdb::unordered_map` here won't hurt.
Simon Marchi [Mon, 4 Nov 2024 18:27:51 +0000 (13:27 -0500)]
Convert all_bfds to new hash table
This converts gdb_bfd.c to use the new hash table for all_bfds.
This patch slightly changes the htab_t pretty-printer test, which was
relying on all_bfds. Note that with the new hash table, gdb-specific
printers aren't needed; the libstdc++ printers suffice -- in fact,
they are better, because the true types of the contents are available.
Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:50 +0000 (13:27 -0500)]
Convert typedef hash to new hash table
This converts the typedef hash to use the new hash table.
This patch found a latent bug in the typedef code. Previously, the
hash function looked at the type name, but the hash equality function
used types_equal -- but that strips typedefs, meaning that equality of
types did not imply equality of hashes. This patch fixes the problem
and updates the relevant test.
Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:47 +0000 (13:27 -0500)]
Convert gnu-v3-abi.c to new hash table
This converts gnu-v3-abi.c to use the new hash table.
This change shows how a std::vector can easily be made directly from
the hash table, simplifying the earlier approach of constructing a
vector and a hash table at the same time.
Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:38 +0000 (13:27 -0500)]
Convert linespec.c to new hash table
This converts linespec.c to use the new hash table.
Note that more simplification could perhaps be done. Currently, the
collectors in this code insert an element into a set and then, if the
element has not been seen before, append it to a vector. If we know
the order does not matter, or if the results can be sorted later, we
could dispense with the vector. This would simplify the code some
more. (This technique is used in the vtable patch, later in this
series.)
Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2 Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:36 +0000 (13:27 -0500)]
Convert compile-c-symbols.c to new hash table
This converts compile-c-symbols.c to use the new hash table.
I made it use a set of string_view instead of a set of `symbol *`, to
avoid calling `symbol::natural_name` over and over. This appears safe
to do, since I don't expect the storage behing the natural names to
change during the lifetime of the map.
Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 4 Nov 2024 18:27:35 +0000 (13:27 -0500)]
gdbsupport: add unordered_dense.h 4.4.0
Add a copy of unordered_dense.h from [1]. This file implements an
efficient hash map and hash set with a nice C++ interface (a near
drop-in for std::unordered_map and std::unordered_set). This is
expected to be used to replace uses of `htab_t`, for improved code
readability and type safety. Performance-wise, it is preferred to the
std types (std::unordered_map and std::unordered_set) due to it using
open addressing vs closed addressing for the std types.
I chose this particular implementation because it is simple to use, it's
a standalone header and it typically performs well in benchmarks I have
seen (e.g. [2]). The license being MIT, my understanding is that it's
not a problem to use it and re-distribute it.
Add two additional files, gdbsupport/unordered_map.h and
gdbsupport/unordered_set.h, which make the map and set offered by
gdbsupport/unordered_dense.h available as gdb::unordered_map and
gdb::unordered_set.
Simon Marchi [Mon, 4 Nov 2024 18:27:32 +0000 (13:27 -0500)]
gdb: rename abbrev_cache to abbrev_table_cache
This cache holds `abbrev_table` objects, so I think it's clearer and
more consistent to name it `abbrev_table_cache`. Rename it and
everything that goes along with it.
Change-Id: I43448c0aa538dd2c3ae5efd2f7b3e7b827409d8c Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Mon, 11 Nov 2024 21:45:17 +0000 (21:45 +0000)]
gdb: do better in breakpoint_free_objfile
The breakpoint_free_objfile function is called from the objfile
destructor, and has the job of removing references to the soon to be
deleted objfile from all breakpoint locations.
The current implementation of breakpoint_free_objfile seems to miss
lots of possible objfile references within bp_location. Currently we
only check if bp_location::symtab is associated with the objfile in
question, but there's bp_location::section and bp_location::probe,
both of which might reference the soon to be deleted objfile.
Additionally bp_location::symbol and bp_location::msymbol if set will
surely be related to the objfile and should also be cleaned up.
I'm not aware that this causes any problems, but it doesn't seem like
a good idea to retain pointers to deleted state, so I propose that we
improve breakpoint_free_objfile to set these pointers back to nullptr.
In the future I plan to investigate the possibility of merging the
functionality of breakpoint_free_objfile into
disable_breakpoints_in_freed_objfile which is called via the
gdb::observers::free_objfile event. However, I already have a patch series
in progress which touches this area of GDB, and I'd like to avoid
conflicting with that earlier series:
Once this patch, and that earlier series have landed then I'll see if
I can merge breakpoint_free_objfile, but I don't think that this needs
to block this patch.
There should be no user visible changes after this commit.
Andrew Burgess [Tue, 5 Nov 2024 13:42:57 +0000 (13:42 +0000)]
gdb: remove an unnecessary scope block in update_breakpoint_locations
In update_breakpoint_locations there's a scope block which I don't
think adds any value. There is one local defined within the scope,
the local is currently an 'int' but should be a 'bool', either way
there's no destructor being triggered when we exit the scope.
This commit changes the local to a 'bool', removes the unnecessary
scope, and re-indents the code.
Within the (now removed) scope was a `for' loop. Inside the loop I
have converted this:
for (....)
{
if (CONDITION)
{
/* Body */
}
}
to this:
for (....)
{
if (!CONDITION)
continue;
/* Body */
}
which means that the body doesn't need to be indented as much, making
things easier to read.
There should be no functional change after this commit.
Reviewed-By: Klaus Gerlicher <klaus.gerlicher@intel.com>
Recalculate the checksum and replace whatever is at the end
of the packet with the newly calculated checksum. Then
replay the packet with the checksum added.
The motivation for this change is that I'd like to add a TCL test
which starts a communication with gdbsever setting the remotelog file.
Then, it modifies the remotelog, injects an error message instead of
the expected replay to some packet in order to test GDB reacts to
the error response properly.
Andrew Burgess [Tue, 5 Nov 2024 17:26:13 +0000 (17:26 +0000)]
gdb/testsuite: force TERM setting for some filename completion tests
Some of the filename completion tests perform mid-line completion.
That is we enter a partial line, then move the cursor back to the
middle of the line and perform completion.
The problem is that, emitting characters into the middle of a terminal
line relies on first emitting some control characters. And which
control characters are emitted will depend on the current TERM
setting.
When I initially added the mid-line completion tests I setup two
regexp that covered two different terminal types, but PR gdb/32338
identifies additional terminal types that emit different sequences of
control characters.
Rather than trying to handle all possible terminal types, lets just
force the TERM variable to something simple (i.e. "dumb") and then
just support that one case. The thing being tested for here was that
GDB would complete a filename in the middle of a line, the specific
terminal type was not really important.
I've simplified the regexp used to match the completion in two places,
and I now force TERM to be "dumb" for the mid-line completion tests.
I've tested this by setting my global environment TERM to 'ansi',
'xterm', 'xterm-mono', and 'dumb', and I see no failures in any mode
now.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32338 Tested-By: Tom de Vries <tdevries@suse.de>
Hui Li [Mon, 25 Nov 2024 07:50:42 +0000 (15:50 +0800)]
gdb: Add LoongArch process record/replay support in NEWS and doc
At present, process record/replay and reverse debugging has been
implemented on LoongArch. Update the NEWS and doc to record this
new change.
Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:46:00 +0000 (15:46 +0800)]
gdb: LoongArch: Add system call support for process record/replay
The process record and replay function also need record Linux
system call instruction. This patch adds LoongArch system call
number definitions in gdb/arch/loongarch-syscall.h, and adds
loongarch_linux_syscall_record() in gdb/loongarch-linux-tdep.c
to record system call execute log. With this patch, the main
functions of process record/replay and reverse debugging are
implemented.
The LoongArch system call numbers definitions are obtained from Linux kernel.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/unistd.h
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/unistd.h
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full) Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:40:03 +0000 (15:40 +0800)]
gdb: LoongArch: Add basic process record/replay support
GDB provides a special process record and replay target that can
record a log of the process execution, and replay it later with
both forward and reverse execution commands. This patch adds the
basic support of process record and replay on LoongArch, it allows
users to debug basic LoongArch instructions and provides reverse
debugging support.
Here is a simple example on LoongArch:
$ cat test.c
int a = 0;
int main()
{
a = 1;
a = 2;
return 0;
}
$ gdb test
...
(gdb) start
...
Temporary breakpoint 1, main () at test.c:4
4 a = 1;
(gdb) record
(gdb) p a
$1 = 0
(gdb) n
5 a = 2;
(gdb) n
6 return 0;
(gdb) p a
$2 = 2
(gdb) rn
5 a = 2;
(gdb) rn
Reached end of recorded history; stopping.
Backward execution from here not possible.
main () at test.c:4
4 a = 1;
(gdb) p a
$3 = 0
(gdb) record stop
Process record is stopped and all execution logs are deleted.
(gdb) c
Continuing.
[Inferior 1 (process 129178) exited normally]
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Guinevere Larsen <guinevere@redhat.com> (record-full) Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Hui Li [Mon, 25 Nov 2024 07:31:34 +0000 (15:31 +0800)]
gdb: LoongArch: Add instruction definition for process record
GDB provides a special process record function that can record a log
of the process execution. The core of this feature is need to record
the execution of all instructions. This patch adds opcode definitions
and judgments in gdb/arch/loongarch-insn.h. This is preparation for
later patch on LoongArch, there is no effect for the other archs with
this patch.
The LoongArch opcode and mask definitions are obtained from
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/loongarch-opc.c
LoongArch instruction description refer to the LoongArch Reference Manual:
https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html
Signed-off-by: Hui Li <lihui@loongson.cn> Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Tom Tromey <tom@tromey.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom de Vries [Sun, 24 Nov 2024 08:21:28 +0000 (09:21 +0100)]
opcodes: fix Werror=format build breaker in opcodes/riscv-dis.c
I build gdb on arm-linux and ran into:
...
CC riscv-dis.lo
opcodes/riscv-dis.c: In function ‘print_insn_args’:
opcodes/riscv-dis.c:743:29: error: format ‘%lu’ expects argument of type \
‘long unsigned int’, but argument 4 has type ‘insn_t’ \
{aka ‘long long unsigned int’} [-Werror=format=]
743 | "%lu", EXTRACT_ZCMT_INDEX (l));
| ~~^
| |
| long unsigned int
| %llu
...
Fix this by printing the insn_t value, which is a uint64_t, using PRIu64.
Tom de Vries [Sat, 23 Nov 2024 12:07:38 +0000 (13:07 +0100)]
[gdb/contrib] Add two words to common-misspellings.txt
While reviewing changes generated by spellcheck.sh for directory sim, I
noticed two more misspellings:
...
arrithemetic->arithmetic
electricaly->electrically
...
Add them to common-misspellings.txt, and fix them in directory sim.
Tom de Vries [Sat, 23 Nov 2024 11:20:34 +0000 (12:20 +0100)]
[gdb/contrib] Add two rules in common-misspellings.txt
Eli mentioned [1] that given that we use US English spelling in our
documentation, we should use "behavior" instead of "behaviour".
In wikipedia-common-misspellings.txt there's a rule:
...
behavour->behavior, behaviour
...
which leaves this as a choice.
Add an overriding rule to hardcode the choice to common-misspellings.txt:
...
behavour->behavior
...
and add a rule to rewrite behaviour into behavior:
...
behaviour->behavior
...
and re-run spellcheck.sh on gdb*.
Guinevere Larsen [Thu, 14 Nov 2024 12:31:00 +0000 (09:31 -0300)]
gdb/record: introduce recoding support for vpor
This commit adds recording support for the AVX instruction vpor, and the
AVX2 extension. Since the encoding of vpor and vpxor are the same, and
their semantics are basically the same, modulo the mathematical
operation, they are handled by the same switch case block.
This also updates the vpxor function, to test vpor and vpxor, and
updates the name to vpor_xor_test to better reflect what it does.
Guinevere Larsen [Tue, 12 Nov 2024 20:45:05 +0000 (17:45 -0300)]
gdb/record: Add support for recording vpmovmskb
This commit adds support for recording the AVX instruction vpmovmskb,
and tests to the relevant file. The test didn't really support checking
general purpose registers, so this commit also adds a proc to
gdb.reverse/i386-avx-reverse.exp, which can be used to test them
Guinevere Larsen [Tue, 12 Nov 2024 19:37:32 +0000 (16:37 -0300)]
gdb/record: Add support for all vpcmpeq instructions
This commit adds support to recording instructions of the form
VPCMPEQ[B|W|D]. They are all encoded in the same way and only
differentiated by the opcode, so they are all processed together. This
commit also updates the test to (quite exhaustively) test the new
instruction.
This commit adds support for recording the instruction vpxor,
introduced in the AVX extension, and extended in AVX2 to use 256 bit
registers. The test gdb.reverse/i386-avx-reverse.exp has been extended
to test this instruction as well.
Guinevere Larsen [Thu, 20 Jun 2024 17:52:35 +0000 (14:52 -0300)]
gdb: Introduce RAII signal handler setter
This patch is motivated by the wait function for the record-full target,
that would install a custom signal handler for SIGINT, but could throw
an exception and never reset the SIGINT handler. This is clearly a bad
idea, so this patch introduces the class scoped_signal_handler in a new
.h file. The file is added to gdbsupport, even though only gdb code is
using it, because it feels like an addition that would be useful for
more than just directly gdb.
The implementation of the RAII class is based on the implementation
on gdb/utils.c. That is, it uses preprocessor ifdefs to probe for
sigaction support, and uses it if possible, defaulting to a raw call to
signal only if sigaction isn't supported. sigaction is preferred based
on the "portability" section of the manual page for the signal function.
There are 3 places where this class can just be dropped in,
gdb/record-full.c, gdb/utils.c and gdb/extension.c. This third place
already had a specialized RAII signal handler setter, but it is
substituted for the new general purpose one.
Hannes Domani [Fri, 22 Nov 2024 19:10:22 +0000 (20:10 +0100)]
Use appropriate context flags for Wow64 processes
When I implemented debugging of Wow64 processes, I missed that there are
extra ContextFlags defines for them.
It's a bit surprising that the wrong ones actually worked, except that
CONTEXT_EXTENDED_REGISTERS is not available for x86_64, and they are
needed for i686, since that's where the xmm registers are stored.
So this replaces the ContextFlags values with their WOW64_* equivalents.
On gdbserver this also duplicates the fallback logic if the
GetThreadContext call failed with CONTEXT_EXTENDED_REGISTERS.
Fixes these fails:
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm0
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm0
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm1
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm1
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm2
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm3
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm3
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm4
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm4
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm5
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm5
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm6
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm6
FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm7
FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm7
FAIL: gdb.arch/i386-sse.exp: check contents of data[0]
FAIL: gdb.arch/i386-sse.exp: check contents of data[1]
FAIL: gdb.arch/i386-sse.exp: check contents of data[2]
FAIL: gdb.arch/i386-sse.exp: check contents of data[3]
FAIL: gdb.arch/i386-sse.exp: check contents of data[4]
FAIL: gdb.arch/i386-sse.exp: check contents of data[5]
FAIL: gdb.arch/i386-sse.exp: check contents of data[6]
FAIL: gdb.arch/i386-sse.exp: check contents of data[7]
Tom de Vries [Fri, 22 Nov 2024 18:34:24 +0000 (19:34 +0100)]
[gdb/python] Handle failure to initialize without exiting
I tried out making python initialization fail by passing an incorrect
PYTHONHOME, and got:
...
$ PYTHONHOME=foo ./gdb.sh -q
Python path configuration:
PYTHONHOME = 'foo'
...
Python initialization failed: \
failed to get the Python codec of the filesystem encoding
Python not initialized
$
...
The relevant part of the code is:
...
static void
gdbpy_initialize (const struct extension_language_defn *extlang)
{
if (!do_start_initialization () && py_isinitialized && PyErr_Occurred ())
gdbpy_print_stack ();
gdbpy_enter enter_py;
...
What happens is:
- gdbpy_enter::gdbpy_enter () is called, where we run into:
'if (!gdb_python_initialized) error (_("Python not initialized"));'
- the error propagates to gdb's toplevel
- gdb print the error and exits.
It seems unnecesssary that we exit gdb. We could continue the
session without python support.
Fix this by:
- bailing out of gdbpy_initialize if !do_start_initialization
- bailing out of finalize_python if !gdb_python_initialized
This gets us instead:
...
$ PYTHONHOME=foo gdb -q
Python path configuration:
PYTHONHOME = 'foo'
...
Python initialization failed: \
failed to get the Python codec of the filesystem encoding
(gdb) python print (1)
Python not initialized
(gdb)
...
Tom de Vries [Fri, 22 Nov 2024 18:34:24 +0000 (19:34 +0100)]
[gdb/python] Fix abort on Py_Initialize
I tried out making python initialization fail by passing an incorrect
PYTHONHOME with python 3.6, and got:
...
$ PYTHONHOME=foo gdb -q
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
Current thread 0x0000ffff89269c80 (most recent call first):
This is as per spec: when Py_Initialize () fails, a fatal error is raised
using Py_FatalError.
This can be worked around using:
...
$ PYTHONHOME=foo gdb -q -eiex "set python ignore-environment on"
(gdb)
...
but it would be better if gdb didn't abort.
I found an article [1] describing two solutions:
- try out Py_Initialize in a separate process, and
- catch the abort using a signal handler.
This patch implements the latter solution.
Obviously we cannot call into python anymore after the abort, so we avoid
calling Py_IsInitialized (), and instead use a new variable py_isinitialized.
This gets us instead:
...
$ PYTHONHOME=foo gdb -q
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'
Current thread 0x0000fffecfd49c80 (most recent call first):
Python not initialized
$
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR python/32379
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379
Tom de Vries [Fri, 22 Nov 2024 18:34:24 +0000 (19:34 +0100)]
[gdb/python] Handle !Py_IsInitialized () in gdbpy_initialize
I tried out making python initialization fail by passing an incorrect
PYTHONHOME, and got:
...
$ PYTHONHOME=foo gdb -q
Python path configuration:
PYTHONHOME = 'foo'
...
Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings'
Python not initialized
$
...
The relevant part of the code is:
...
static void
gdbpy_initialize (const struct extension_language_defn *extlang)
{
if (!do_start_initialization () && PyErr_Occurred ())
gdbpy_print_stack ();
gdbpy_enter enter_py;
...
What happens is that:
- do_start_initialization returns false because Py_InitializeFromConfig fails,
leaving us in the !Py_IsInitialized () state
- PyErr_Occurred () returns true
- gdbpy_print_stack is called, which prints
"Python Exception <class 'ModuleNotFoundError'>: No module named 'encodings"
The problem is that in the Py_IsInitialized () == false state, very few
functions can be called, and PyErr_Occurred is not one of them [1], and
likewise functions in gdbpy_print_stack.
Fix this by:
- guarding the PyErr_Occurred / gdbpy_print_stack part with Py_IsInitialized ().
- handling the !Py_IsInitialized () case by printing the failure PyStatus
in do_start_initialization
This gets us instead:
...
$ PYTHONHOME=foo ./gdb.sh -q
Python path configuration:
PYTHONHOME = 'foo'
...
Python initialization failed: failed to get the Python codec of the filesystem encoding
Python not initialized
$
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://docs.python.org/3/c-api/init.html#before-python-initialization
Tom de Vries [Fri, 22 Nov 2024 16:44:29 +0000 (17:44 +0100)]
[gdbsupport] Add gdb::{waitpid,read,write,close}
We have gdb::handle_eintr, which allows us to rewrite:
...
ssize_t ret;
do
{
errno = 0;
ret = ::write (pipe[1], "+", 1);
}
while (ret == -1 && errno == EINTR);
...
into:
...
ssize_t ret = gdb::handle_eintr (-1, ::write, pipe[1], "+", 1);
...
However, the call to write got a bit mangled, requiring effort to decode it
back to its original form.
Instead, add a new function gdb::write that allows us to write:
...
ssize_t ret = gdb::write (pipe[1], "+", 1);
...
Andrew Burgess [Mon, 18 Nov 2024 10:58:26 +0000 (10:58 +0000)]
gdb/disasm: fix demangling when disassembling the current function
When disassembling function symbols in C++ code, if GDB is asked to
disassemble a function by name then the function name in the header
line can be demangled by turning on `set print asm-demangle on`, e.g.:
(gdb) disassemble foo_type::some_function
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
(gdb) set print asm-demangle on
(gdb) disassemble foo_type::some_function
Dump of assembler code for function foo_type::some_function(my_type):
0x0000000000401142 <+0>: push %rbp
... etc ... │
End of assembler dump. │
However, if GDB is disassembling the current function, then this
demangling doesn't work, e.g.:
(gdb) break foo_type::some_function
Breakpoint 1 at 0x401152: file mangle.cc, line 16.
(gdb) run
Starting program: /tmp/mangle
Breakpoint 1, foo_type::some_function (this=0x7fffffffa597, obj=...) at mangle.cc:16
16 obj.update ();
(gdb) disassemble
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
(gdb) set print asm-demangle on
(gdb) disassemble
Dump of assembler code for function _ZN8foo_type13some_functionE7my_type:
0x0000000000401142 <+0>: push %rbp
... etc ...
End of assembler dump.
This commit fixes this issue, and extends gdb.cp/disasm-func-name.exp,
which was already testing the first case (disassemble by name) to also
cover disassembling the current function.
Tom de Vries [Fri, 22 Nov 2024 16:34:50 +0000 (17:34 +0100)]
[gdb/python] Ensure locale is restored in do_start_initialization
I noticed in do_start_initialization:
...
std::string oldloc = setlocale (LC_ALL, NULL);
setlocale (LC_ALL, "");
...
if (count == (size_t) -1)
{
fprintf (stderr, "Could not convert python path to string\n");
return false;
}
setlocale (LC_ALL, oldloc.c_str ());
...
that the old locale is not restored if the "return false" is triggered.
Sam James [Mon, 18 Nov 2024 05:53:54 +0000 (05:53 +0000)]
libiberty: sync with gcc
This imports the following commits from GCC as of r15-5375-gbeec291225be9b: 94bea5dd6c9a libiberity: ANSIfy test-demangle.c aa84020b2edb libiberty: Fix comment typos c1b2100e736c libiberty: Restore build with CP_DEMANGLE_DEBUG defined bb8dd0980b39 libiberty: Fix up > 64K section handling in simple_object_elf_copy_lto_debug_section [PR116614]
Simplify amd64_windows_store_arg_in_reg by:
- replacing memset with value initialization,
- making valbuf a gdb::array_view, allowing us to:
- replace memcpy with std::copy, and
- use valbuf.size () instead of arg->type->size (), and
- dropping the std::min in std::min (type->length (), (ULONGEST) 8), since
we're already asserting that type->length () <= 8.
Suggested-By: Tom Tromey <tom@tromey.com>
Tested by rebuilding on x86_64-linux.
Tom de Vries [Fri, 22 Nov 2024 11:54:57 +0000 (12:54 +0100)]
[gdb/build] Workaround tsan select bug
When building gdb with -O0 and -fsanitize-thread, I run into a large number of
timeouts caused by gdb hanging, for instance:
...
(gdb) continue^M
Continuing.^M
[Inferior 1 (process 378) exited normally]^M
FAIL: gdb.multi/stop-all-on-exit.exp: continue until exit (timeout)
...
What happens is the following:
- two inferiors are added, stopped at main
- inferior 1 is setup to exit after 1 second
- inferior 2 is setup to exit after 10 seconds
- the continue command is issued
- because of set schedule-multiple on, both inferiors continue
- the first inferior exits
- gdb sends a SIGSTOP to the second inferior
- the second inferior receives the SIGSTOP, and raises a SIGCHILD
- gdb calls select, and blocks
- the signal arrives, and interrupts select
- ThreadSanitizers signal handler is called, which marks the signal pending
internally
- select returns -1 with errno == EINTR
- gdb calls select again, and blocks
- gdb hangs, waiting for gdb's sigchild_handler to be called
This is a bug [1] in ThreadSanitizer. When select is called with
timeout == nullptr, it is blocking but ThreadSanitizer doesn't consider it so,
and consequently doesn't see the need to call sigchild_handler.
Work around this by:
- instead of using the blocking select variant, forcing a small timeout and
- upon timeout calling a function that ThreadSanitizer does consider
blocking: usleep, forcing sigchild_handler to be called.
Tom de Vries [Fri, 22 Nov 2024 11:54:57 +0000 (12:54 +0100)]
[gdb] Add gdb_select variant for looping
In interruptible_select we run gdb_select in a loop:
...
do
{
res = gdb_select (n, readfds, writefds, exceptfds, timeout);
}
while (res == -1 && errno == EINTR);
...
but man select tells us that:
- if using select() within a loop, the sets (readfds, writefds and
exceptfds) must be reinitialized before each call, and
- timeout should be considered to be undefined after select() returns.
Add a gdb_select variant:
...
static int
gdb_select (int n,
const fd_set *req_readfds, fd_set *ret_readfds,
const fd_set *req_writefds, fd_set *ret_writefds,
const fd_set *req_exceptfds, fd_set *ret_exceptfds,
const struct timeval *req_timeout, struct timeval *ret_timeout)
...
that keeps requested and returned values separate, ensuring that the requested
values stay constant.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Martin Storsjö [Fri, 6 Sep 2024 13:18:02 +0000 (16:18 +0300)]
ld/PE: Handle MS style import libraries for files named *.exe too
When handling MS style import libraries (also called short import
libraries, or ILF), we need to detect the kind of library.
So far, this has been done by looking at the member file names
in the import library - in an MS style import library, all the
member files for a specific library have the same member file
name - the name of the runtime module to link against. Usually
this is a DLL - thus we do a case insensitive comparison and
check if the suffix is .dll.
However, an .exe can also export symbols which can be linked
against in the same way. In particular, if linking against
WDK (Windows Driver Kit) import libraries, e.g. wdmsec.lib, the
import libraries can provide imports for ntoskrnl.exe.
Instead of specifically checking for *.dll (and *.exe, etc),
invert the condition and skip archive members named *.o and *.obj.
For any remaining archive members, that do contain .idata
sections, apply the renaming. (The renaming is also mostly
harmless if applied where it isn't needed; if archive members
already have unique file names, their relative ordering should
remain intact except for very contrieved cases.)
Nelson Chu [Wed, 20 Nov 2024 08:30:39 +0000 (16:30 +0800)]
RISC-V: Support SiFive extensions: xsfvqmaccdod, xsfvqmaccqoq and xsfvfnrclipxfqf
Those SiFive extensions have been published on the web for a while, and we plan
to implement intrinsics in GCC for those instructions soon.
NOTE: The original patch was written by Nelson when he was still working at
SiFive, and Kito rebased it to the trunk. Therefore, I kept the author as Nelson
with his SiFive email.
Tom Tromey [Wed, 13 Nov 2024 15:49:53 +0000 (08:49 -0700)]
Don't put JIT_READER_DIR into help text
The 80-column-help-string self-test can fail if gdb's install
directory is too long, because the help for "jit-reader-load" includes
JIT_READER_DIR.
This help text is actually somewhat misleading, though.
JIT_READER_DIR is not actually used directly -- instead the relocated
variant is used.
This patch adds a new "show jit-reader-directory" command and changes
the help text to refer to this instead. I considered adding a "set"
command as well, but since absolute paths are acceptable here, and
since this is a very niche command anyway, I figured there was no need
to bother.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32357 Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
Andrew Burgess [Mon, 18 Nov 2024 16:19:43 +0000 (16:19 +0000)]
gdb/build-id: protect against weirdly short build-ids
While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised
that GDB would likely not do what we wanted if a build-id was ever a
single byte.
Right now, build-ids generated by the GNU linker are 32 bytes, but
there's nothing that forces this to be the case, it's pretty easy to
create a fake, single byte, build-id. Given that the build-id is an
external input (read from the objfile), GDB should protect itself
against these edge cases.
The problem with build_id_to_bfd_suffix is that this function creates
the path used to lookup either the debug information, or an
executable, based on its build-id. So a 3-byte build-id 0xaabbcc will
look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`.
However, a single byte build-id 0xaa, will look in the file:
`$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right.
Worse, when looking for an objfile given a build-id GDB will look for
a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing
'/' character.
I propose that, in build_id_to_bfd_suffix we just return early if the
build-id is 1 byte (or less) with a return value that indicates no
separate file was found.
For testing I made use of the DWARF assembler. I needed to update the
build-id creation proc, the existing code assumes that the build-id is
a multiple of 4 bytes, so I added some additional padding to ensure
that the generated note was a multiple of 4 bytes, even if the
build-id was not.
I added a test with a 1 byte build-id, and also for the case where the
build-id has zero length. The zero length case already does what
you'd expect (no debug is loaded) as the bfd library rejects the
build-id when loading it from the objfile, but adding this additional
test is pretty cheap.
Rohr, Stephan [Thu, 19 Sep 2024 10:55:19 +0000 (12:55 +0200)]
testsuite: skip confirmation in 'gdb_reinitialize_dir'
Some shells automatically confirm the 'dir' command:
(gdb) dir
Reinitialize source path to empty? (y or n)
[answered Y; input not from terminal]
Source directories searched: $cdir;$cwd
(gdb) y
dir <...>/gdb/testsuite/gdb.base
Undefined command: "y". Try "help".
For example, this reprdocues in a MinGW32 environment with
'TERM=dumb'. Skip sending 'y' if the command is already confirmed.
Tom Tromey [Mon, 4 Nov 2024 14:31:20 +0000 (07:31 -0700)]
Improve choice sorting in ada-lang.c
ada-lang.c has a "sort_choices" function that claims to sort the
symbol choices, but which does not really implement sorting. This
patch changes this code to really sort the result vector, sorting
first by filename, then line number, and finally by the symbol name.
The filename sorting is done first by comparing basenames. It turns
out that gnatmake and gprbuild invoke the compiler a bit differently,
so depending on which one you use, the results of a naive sort might
be different (due to the use of absolute or relative paths).
Andre Vieira [Wed, 20 Nov 2024 17:15:28 +0000 (17:15 +0000)]
arm: Support pac_key_* register operand for MRS/MSR in Armv8.1-M Mainline
Add support for pac_key_[pu]_[0-3](_ns)? register operands for the MRS and MSR
instructions when assembling for Armv8.1-M Mainline, as well as adding the
corresponding support for disassembling instructions that use it.
Andrew Burgess [Tue, 19 Nov 2024 10:37:49 +0000 (10:37 +0000)]
gdb/python: fix reference leak in gdb.BreakpointLocation.thread_groups
While reviewing another patch which uses PyList_Append I took a look
at our other uses of PyList_Append in GDB. I spotted something odd
about the use in bplocpy_get_thread_groups.
We do:
gdbpy_ref<> num = gdb_py_object_from_ulongest (inf->num);
At which point `num` will own a reference to the `int` object. But
when we add the object to the result list we do:
if (PyList_Append (list.get (), num.release ()) != 0)
return nullptr;
By calling `release` we pass ownership of the reference to
PyList_Append, however, PyList_Append acquires its own reference, it
doesn't take ownership of an existing reference.
The consequence of this is that we leak the reference held in `num`.
This mostly isn't a problem though. For small (< 257) integers Python
keeps a single instance of each and just hands out new references. By
leaking the references, these small integers will not be cleaned up as
the Python interpreter shuts down, but that is only done when GDB
exits, so hardly a disaster. As we're dealing with GDB's internal
inferior number here, unless the user has 257+ inferiors, we'll not
actually be leaking memory.
Still, lets do things right. Switch to using `num.get ()`. Now when
`num` goes out of scope it will decrement the reference count as
needed.
Jiawei [Tue, 29 Oct 2024 12:44:23 +0000 (20:44 +0800)]
RISC-V: Add Zcmt instructions and csr.
This patch supports Zcmt[1] instruction 'cm.jt' and 'cm.jalt'.
Add new CSR jvt for tablejump using. Since 'cm.jt' and 'cm.jalt'
have the same instructiong encoding, use 'match_cm_jt' and 'match_cm_jalt'
check the 'zcmt_index' field to distinguish them.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
bfd/ChangeLog:
* elfxx-riscv.c (riscv_multi_subset_supports): New extension.
(riscv_multi_subset_supports_ext): Ditto.
gas/ChangeLog:
* config/tc-riscv.c (enum riscv_csr_class): New CSR.
(riscv_csr_address): Ditto.
(validate_riscv_insn): New operand.
(riscv_ip): Ditto.
* testsuite/gas/riscv/csr-version-1p10.d: New CSR.
* testsuite/gas/riscv/csr-version-1p10.l: Ditto.
* testsuite/gas/riscv/csr-version-1p11.d: Ditto.
* testsuite/gas/riscv/csr-version-1p11.l: Ditto.
* testsuite/gas/riscv/csr-version-1p12.d: Ditto.
* testsuite/gas/riscv/csr-version-1p12.l: Ditto.
* testsuite/gas/riscv/csr.s: Ditto.
* testsuite/gas/riscv/march-help.l: New extension.
* testsuite/gas/riscv/zcmt-fail.d: New test.
* testsuite/gas/riscv/zcmt-fail.l: New test.
* testsuite/gas/riscv/zcmt-fail.s: New test.
* testsuite/gas/riscv/zcmt.d: New test.
* testsuite/gas/riscv/zcmt.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h (MATCH_CM_JT): New opcode.
(MASK_CM_JT): New mask.
(MATCH_CM_JALT): New opcode.
(MASK_CM_JALT): New mask.
(CSR_JVT): New CSR.
(DECLARE_INSN): New declaration.
(DECLARE_CSR): Ditto.
* opcode/riscv.h (EXTRACT_ZCMT_INDEX): New marco.
(ENCODE_ZCMT_INDEX): Ditto.
(enum riscv_insn_class): New class.
opcodes/ChangeLog:
* riscv-dis.c (print_insn_args): New operand.
* riscv-opc.c (match_cm_jt): New function.
(match_cm_jalt): Ditto.
Tom de Vries [Tue, 19 Nov 2024 11:32:40 +0000 (12:32 +0100)]
[gdb/contrib] Fix shellcheck warnings in spellcheck.sh
Fix shellcheck warnings in spellcheck.sh, found using shellcheck v0.10.0.
Ran shellcheck v0.10.0 (on a system with shellcheck version 0.8.0) using this
command from an RFC patch [1]:
...
$ ./gdb/contrib/pre-commit-shellcheck.sh ./gdb/contrib/spellcheck.sh
...
Nelson Chu [Tue, 8 Oct 2024 04:35:43 +0000 (12:35 +0800)]
RISC-V: Don't report warnings when linking different privileged spec objects.
Since only the abandoned privileged spec v1.9.1 will have conflict csrs, to
keep the compatible we still report warnings when linking privileged spec
v1.9.1 objects with others. But don't report warnings for other compatible
cases because it is actually a bit noisy and useless...
bfd/
* elfnn-riscv.c (riscv_merge_attributes): Only report warnings when
linking the abandoned privileged spec v1.9.1 object with others.
ld/
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Removed.
* testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Removed.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
Lulu Cai [Tue, 5 Nov 2024 08:21:28 +0000 (16:21 +0800)]
LoongArch: Do not relax pcalau12i+ld.d when there is overflow
There is no overflow check for the relaxation of pcalau12i+ld.d =>
pcalau12i+addi.d. For instruction sequences that can be relaxed,
they are directly relaxed to pcalau12i+addi.d. However, when the
relative distance between the symbol and the pc exceeds the 32-bit
range, the symbol value cannot be obtained correctly.
Adds an overflow check for the relaxation of pcalau12i+ld.d.
If it is found that the relaxation will overflow, it will not
be relaxed.
LAM: Enable tagged pointer support for watchpoints.
The Intel (R) linear address masking (LAM) feature modifies the checking
applied to 64-bit linear addresses. With this so-called "modified
canonicality check" the processor masks the metadata bits in a pointer
before using it as a linear address. LAM supports two different modes that
differ regarding which pointer bits are masked and can be used for
metadata: LAM 48 resulting in a LAM width of 15 and LAM 57 resulting in a
LAM width of 6.
This patch adjusts watchpoint addresses based on the currently enabled
LAM mode using the untag mask provided in the /proc/<pid>/status file.
As LAM can be enabled at runtime or as the configuration may change
when entering an enclave, GDB checks enablement state each time a watchpoint
is updated.
In contrast to the patch implemented for ARM's Top Byte Ignore "Clear
non-significant bits of address on memory access", it is not necessary to
adjust addresses before they are passed to the target layer cache, as
for LAM tagged pointers are supported by the system call to read memory.
Additionally, LAM applies only to addresses used for data accesses.
Thus, it is sufficient to mask addresses used for watchpoints.
The following examples are based on a LAM57 enabled program.
Before this patch tagged pointers were not supported for watchpoints:
~~~
(gdb) print pi_tagged
$2 = (int *) 0x10007ffffffffe004
(gdb) watch *pi_tagged
Hardware watchpoint 2: *pi_tagged
(gdb) c
Continuing.
Couldn't write debug register: Invalid argument.
~~~~
Once LAM 48 or LAM 57 is enabled for the current program, GDB can now
specify watchpoints for tagged addresses with LAM width 15 or 6,
respectively.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
The gdbarch function gdbarch_remove_non_address_bits adjusts addresses to
enable debugging of programs with tagged pointers on Linux, for instance for
ARM's feature top byte ignore (TBI).
Once the function is implemented for an architecture, it adjusts addresses for
memory access, breakpoints and watchpoints.
Linear address masking (LAM) is Intel's (R) implementation of tagged
pointer support. It requires certain adaptions to GDB's tagged pointer
support due to the following:
- LAM supports address tagging for data accesses only. Thus, specifying
breakpoints on tagged addresses is not a valid use case.
- In contrast to the implementation for ARM's TBI, the Linux kernel supports
tagged pointers for memory access.
This patch makes GDB's tagged pointer support configurable such that it is
possible to enable the address adjustment for a specific feature only (e.g
memory access, breakpoints or watchpoints). This way, one can make sure
that addresses are only adjusted when necessary. In case of LAM, this
avoids unnecessary parsing of the /proc/<pid>/status file to get the
untag mask.
Reviewed-By: Felix Willgerodt <felix.willgerodt@intel.com>
(AArch64) Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Jan Beulich [Mon, 18 Nov 2024 10:46:28 +0000 (11:46 +0100)]
x86: rename SPACE_{,E}VEX_MAP<N>
Map7 already has dual purpose for USER-MSR (and is to gain more for
MSR-IMM), while Map5 is about to gain VEX uses for AMX extensions. Drop
the not really meaningful infixes and (in the opcode table) prefixes,
retaining merely EVexMap4 for encoding EVex128 at the same time.
projects / thirdparty / binutils-gdb.git / log
