I ran into a failure in test-case gdb.python/py-missing-debug.exp with python
3.6, which was fixed by commit 7db795bc67 ("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
7db795bc67.
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.
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>
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>
This removes the char-based bitfield macros from gdbtypes.h, as they
are no longer used.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This removes TYPE_FIELD_PRIVATE, TYPE_FIELD_PROTECTED,
TYPE_FIELD_IGNORE, and TYPE_FIELD_VIRTUAL.
In c-varobj.c, match_accessibility can be removed entirely now. Note
that the comment before this function was incorrect.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
I think these invocations of QUIT in need_access_label_p are overkill.
QUIT is already called from its caller. This just removes them.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This adds a field::is_public convenience method, and updates one spot
to use it.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
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>
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>
This changes recursive_dump_type to reuse the type-codes.def file when
stringifying type codes.
This version of the patch changes the "unknown" case to an assert.
Acked-By: Simon Marchi <simon.marchi@efficios.com>
Reviewed-by: Keith Seitz <keiths@redhat.com>
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);
^
Fix that.
Change-Id: Iedd58b36777eb77bca9e23f94882b217c9c87059
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.
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 eb42bb1489 ("[gdb/tdep] Fix
catching syscall execve exit for arm").
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
Commit 59a561480d ("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 169fe7ab54 ("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.
After commit 169fe7ab54:
...
0000000000402259 B Barrier
0000000000402020 D TestStrings
...
they're not even in the same section anymore.
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.
Tested on x86_64-linux.
PR testsuite/31064
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31064
Initializers in lambda captures were introduced in C++14, and
conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c.
Since C++17 is now required by GDB, use this feature unconditionally.
Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
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>
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
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>
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>
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>
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>
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
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.
Tested on pinebook.
PR tdep/31071
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31071
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.
Consider a binary with an erroneous size of the .dynamic section:
$ readelf -S a.out
...
[24] .dynamic DYNAMIC 0000000000004c20 00003c20
000000fffffffa40 0000000000000010 WA 7 0 8
...
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Following on from this commit:
commit f2c4f78c81
Date: Thu Sep 21 16:35:30 2023 +0100
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 f2c4f78c81, 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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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>
A simple refactor to make the reference to current_program_space bubble
up one level. No behavior changes expected.
Change-Id: I237cf2f45ae73c35bcb433ce40e3c03cef6b87e2
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).
No behavior change expected.
Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
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
Change-Id: I04fd41b22c83fe486522af7851c75bcfb31c88c7
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.
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.
https://sourceware.org/bugzilla/show_bug.cgi?id=31037
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
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>
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>
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475
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.
Change-Id: I8ec2b1a4b9980c2d565a8aafd060ed070eeb3b29
Remove uses of obstack in the code generating the libraries XML for
Windows and AIX. Use std::string instead. I'm not able to test this
change, unfortunately.
Change-Id: I28480913337e3fe8d6c31e551626931e6b1367ef
Approved-By: Tom Tromey <tom@tromey.com>
compile.exp generally does not work for me on Fedora 38. However, I
sent a GCC patch to fix the plugin crash. With that patch, I get this
error from one test in compile.exp:
gdb command line:1:22: warning: initialization of 'int (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]
This patch adds a cast to compile.exp. This makes the test pass.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This commit:
commit 8f6c452b5a
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
introduced a use of str.isascii(), which was only added in Python 3.7.
This commit switches to use curses.ascii.isascii(), as this was
available in 3.6.
The same is true for str.isalnum(), which is replaced with
curses.ascii.isalnum().
There should be no user visible changes after this commit.
Spotted that we'd gained two 'New commands' sections in our 'Changes
since GDB 14' NEWS file block. I've merged them together.
Also, one of these two sections was actually called 'New Commands',
however, all the other places in the NEWS file use 'New commands', so
I've changed to use that.
Simon noticed that gdb.threads/threads-after-exec.exp was racy. You
can consistenly reproduce it (at git hash
319b460545), with:
$ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp"
gdb.log shows:
(...)
Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290
in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec
info threads
Id Target Id Frame
* 3 process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads
(...)
maint info linux-lwps
LWP Ptid Thread ID
1443269.1443269.0 1.3
(gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps
The FAILs happen because the .exp file expects that after the exec,
the only thread has GDB thread number 1, but it has instead 3.
This is yet another case of zombie leader detection making things a
bit fuzzy.
In the passing case, we have:
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 603183)]
[Thread 0x7ffff7bff640 (LWP 603183) exited]
process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec
While in the failing case, we have (note remarks on the rhs):
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 600205)]
[Thread 0x7ffff7f95740 (LWP 600202) exited] <<< gdb deletes leader thread, thread 1.
[New LWP 600202] <<< gdb adds it back -- this is now thread 3.
[Thread 0x7ffff7bff640 (LWP 600205) exited]
process 600202 is executing new program: .../threads-after-exec/threads-after-exec
The testcase only has two threads, yet GDB presented the exec for
thread 3. This is GDB deleting the leader (the backend detected it
was zombie, due to the exec), and then adding the leader back when it
saw the exec event.
I've recorded some thoughts about this in PR gdb/31069.
For now, this commit just makes the testcase cope with the non-one
thread number, as the number is not important for what this test is
exercising.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069
Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae
If you run gdb in the build tree without --data-directory, on a
program that does not have debug info, it will crash, because
gdbpy_handle_missing_debuginfo unconditionally uses gdb_python_module.
Other code in gdb using gdb_python_module checks it first and it
seemes harmless to do the same thing here. (gdb_python_initialized
does not cover this case so that python can be partially initialized
and still somewhat work.)
This changes ada-nested.exp to fix a test name (the test expects three
variables but is named "two"), and to iterate over all the variables
that are found. It also adds a workaround to a problem Tom de Vries
found with an older version of GNAT -- it emits a duplicate "x".
