| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This converts py-framefilter.c to use the new hash table.
Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This converts breakpoint.c to use the new hash table.
Change-Id: I6d997a6242969586a7f8f9eb22cc8dd8d3ac97ff
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This converts dwarf2/macro.c to use the new hash table.
Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This converts target-descriptions.c to use the new hash table.
Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
This converts filename-seen-cache.h to use the new hash table.
filename-seen-cache.c is removed.
Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a
Co-Authored-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
It can never return nullptr, return a reference instead of a pointer.
Change-Id: Ibc6f16eb74dc16059152982600ca9f426d7f80a4
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Make `abbrev_table_cache::find` const, make it return a pointer to
`const abbrev_table`, adjust the fallouts.
Make `cooked_index_storage::get_abbrev_table_cache` const, make itreturn
a pointer to const `abbrev_table_cache`.
Change-Id: If63b4b3a4c253f3bd640b13bce4a854eb2d75ece
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
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:
https://inbox.sourceware.org/gdb-patches/cover.1724948606.git.aburgess@redhat.com
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.
|
|
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>
|
|
The bp_location::objfile member variable is never used, so lets delete
it.
There should be no user visible changes after this commit.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
Tested by rebuilding on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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*.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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]
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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)
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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):
Fatal signal: Aborted
...
Aborted (core dumped)
$
...
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
[1] https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails
|
|
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
|
|
Use gdb syscall wrappers to handle EINTR in ser-event.c.
Tested on aarch64-linux.
|
|
Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled.
Tested on x86_64-linux.
|
|
Use gdb::waitpid instead of plain waitpid, making sure that EINTR is handled.
Tested on x86_64-linux.
|
|
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);
...
Likewise for waitpid, read and close.
Tested on x86_64-linux.
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
Fix this by using SCOPE_EXIT.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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.
|
|
I noticed that gdb.base/bg-exec-sigint-bp-cond.exp fails for remote host
(concretely, host board local-remote-host and target board
remote-gdbserver-on-localhost):
...
(gdb) c&^M
Continuing.^M
(gdb) bash: line 0: kill: (23834) - Operation not permitted^M
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
...
due to getting gdb's pid like this:
...
set gdb_pid [exp_pid -i [board_info host fileid]]
...
For remote host using ssh, this returns the pid of the ssh session on build.
Fix this by requiring local host.
Tested on x86_64-linux.
|
|
The test-case gdb.base/bg-exec-sigint-bp-cond.exp sends 10 SIGINTS to gdb, and
counts whether 10 have arrived.
Occasionally, less than 10 arrive due to signal merging [1].
This is more likely to happen when building gdb with -fsanitize=thread.
Fix this by instead, sending one SIGINT at a time, and waiting for it to
arrive.
This still makes the test-case fail if the fix fixing the PR that the
test-case was introduced for is reverted.
Tested on aarch64-linux and x86_64-linux.
PR testsuite/32329
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32329
[1] https://www.gnu.org/software/libc/manual/html_node/Merged-Signals.html
|
|
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.
Tested on x86_64-linux.
PR build/32295
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32295
[1] https://github.com/google/sanitizers/issues/1813
|
|
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>
|
|
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>
|
|
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.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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).
|
|
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove some inappropriate comments in darwin_nat_target::attach,
gnu_nat_target::attach and inf_ptrace_target::attach.
Tested by rebuilding on x86_64-linux.
Copyright-paperwork-exempt: yes
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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
...
Tested on x86_64-linux
[1] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html
|
|
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>
|
