Tom Tromey [Mon, 24 Feb 2025 19:26:36 +0000 (12:26 -0700)]
Introduce attribute::signed_constant
This introduces a new method, attribute::signed_constant. This should
be used wherever DWARF specifies a signed integer constant, or where
this is implied by the context. It properly handles sign-extension
for DW_FORM_data*.
To my surprise, there doesn't seem to be a pre-existing sign-extension
function. I've added one to common-utils.h alongside the align
functions.
gdb: update corner case when canonicalizing riscv syscall names
The script syscalls/riscv-canonicalize-syscall-gen.py has been recently
introduced to help support record-full in riscv systems. However, it
was developed before commit 432eca4113d5748ad284a068873455f9962b44fe,
which made the GDB enum more consistent, which forced the python script
to have a corner case for the "gdb_old_mmap" case.
Since the aforementioned commit has already been merged, we need to
update the special case for the mmap syscall. A special case is still
needed because the script would expect that the glibc sources call the
syscall "old_mmap", or that gdb call it "gdb_sys_mmap", neither of which
happens unfortunately.
This commit doesn't change the .c file because it was already fixed by a
different commit, 65ab41b7d5c612b6000b28f4c50bb256b2a9e22b, which was
pushed as obvious to fix the build issues.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-dlobj.exp
This test exercises musl_link_map_to_tls_module_id() and
glibc_link_map_to_tls_module_id(), both of which are in solib-svr4.c.
Prior to writing this test, I had only written what is now named
'musl_link_map_to_tls_module_id' and it worked for both GLIBC and
MUSL. Once I wrote this new test, tls-dlobj.exp, there were a number
of tests which didn't work with GLIBC. This led me to write a
GLIBC-specific link map to module id function, i.e,
'glibc_link_map_to_tls_module_id'.
It only has one compilation scenario, in which the pthread(s) library
is used - as noted in a comment, it became too much of a hassle to try
to KFAIL things, though it certainly could have been done in much the
same was as was done in gdb.base/multiobj.exp. It didn't seem that
important to do so, however, since I believe that the other tests
have adequate coverage for different compilation scenarios.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-multiobj.exp
This test exercises GDB's internal TLS support when both the main
program and several shared libraries have TLS variables. It also
tests existing (non-internal) TLS support too.
It tests using two compilation scenarios, "default", in which
libpthread is not linked with the program and libraries as well
as one which does use libpthread.
It tests link map address to module id mapping code in GDB
in addition to the ability of GDB to traverse TLS data structures
with several libraries in play.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
New test - gdb.base/tls-nothreads.exp
This commit introduces a new test, gdb.base/tls-nothreads.exp.
It has a test case, a C file, which has several TLS variables in the
main program, which, once compiled and linked, should end up (in ELF
files) in .tdata and .tbss. The test compiles the program in a number
of different ways, making sure that each variable is accessible
regardless of how it was compiled.
Note that some of the compilation scenarios end up with a statically
linked executable. Prior to this series of commits, accessing TLS
variables from a statically linked program on Linux did not work.
For certain targets (x86_64, aarch64, s390x, riscv, and ppc64),
all on Linux, support has been added to GDB for accessing thread
local storage in statically linked executables. This test is
important for testing those build scenarios.
But it's also important to make sure that GDB's internal TLS support
works for other scenarios too. In order to accomplish that, the
tests are also run in a mode which forces the internal support to
be used.
It also adds a new file, gdb.base/tls-common.exp.tcl, which includes
some common definitions used by the three new TLS tests, including
the one added by this commit. In particular, it sets a TCL variable,
'internal_tls_linux_targets' which list the targets mentioned earlier.
This means that as internal TLS support is added for other targets,
the target should be listed in just one file as opposed to three
(or more if other tests using tls-common.exp.tcl are added).
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
Internal, but disabled, TLS support for i386
This commit shows how internal TLS address lookup support could
be implemented for the i386 target.
Unfortunately, it doesn't work due to I386_GSBASE_REGNUM being
unavailable for Linux targets. I looked at trying to access the
gsbase register via PTRACE_GET_THREAD_AREA, but did not understand
it well enough to finish it. Since the i386 target is much less
important than it used to be, I gave up working on it.
I don't want to leave this disabled code in our sources, so I
will delete it in the next commit, however, this commit will be
in our git repo, so it'll be available for someone with sufficient
interest in the i386 target to look at.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:29 +0000 (21:39 -0700)]
Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x
For each architecture, aarch64, x86_64, riscv, ppc64, and s390x,
this commit defines a suitable 'get_tls_dtv_addr' method and,
when necessary, a 'get_tls_dtp_offset' method.
It also registers svr4_tls_get_thread_local_address, defined in
svr4-tls-tdep.c (in an earlier commit), as the
get_thread_local_address gdbarch method. It also registers its
architecture specific code using svr4_tls_register_tls_methods().
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Implement internal TLS address lookup for select Linux targets
This commit adds non-architecture-specific support for internal TLS
address lookup for targets which register their support with the new
file svr4-tls-tdep.c. By "internal", I mean support which does not
rely on libthread_db. Knowledge of how to traverse TLS data
structures is contained in this commit along with the next commit
containing architecture specific knowledge regarding TLS offsets,
registers, and such.
The new function 'svr4_tls_get_thread_local_address' is a gdbarch method.
It should be passed as an argument to
set_gdbarch_get_thread_local_address in architecture specific
<arch>-linux-tdep.c files which wish to offer internal TLS support.
The architecture specific tdep files need to define a get_tls_dtv_addr
method - as the name suggests, it needs to return the address of the
DTV (dynamic thread vector) via architecture specific means. This
usually entails fetching the thread pointer via a register or registers
assigned to this purpose, and then using that value to locate the
address of the DTV from within the TCB (thread control block).
Additionally, some architectures also need to provide a DTP offset,
which is used by the MUSL C library to adjust the value obtained
from a DTV entry to that of the start of the TLS block for a particular
thread. This is provided, when necessary, by a get_tls_dtp_offset
method.
Both methods, get_tls_dtv_addr and get_tls_dtp_offset, are registered
with data structures maintained by linux-tdep.c via the new function
svr4_tls_register_tls_methods(). Thus, for example, on RISC-V,
riscv_linux_init_abi() will make the following two calls, the first
for registering the internal get_thread_local_address gdbarch method
and the second for registering riscv-specific methods for obtaining
the DTV address and DTP offset:
Internal TLS support is provided for two C libraries, GLIBC, and MUSL.
Details for accessing the various TLS data structures differ between
these libraries. As a consequence, linux-tdep.h defines a new enum,
svr4_tls_libc, with values svr4_tls_libc_unknown, svr4_tls_libc_musl,
and svr4_tls_libc_glibc. A new static function libc_tls_sniffer uses
heuristics to (try to) decide whether a program was linked against
GLIBC or MUSL. Working out what the heuristics should be, especially
for statically linked binaries, turned out to be harder than I thought
it would be.
A new maintenance setting, force-internal-tls-address-lookup, has been
added, which, when set to 'on', will (as the name suggests) force the
internal TLS lookup mechanisms to be used. Otherwise, if thread_db
support is available (via the thread stratum), that will be preferred
since it should be more accurate. I expect that this setting will be
mostly used by test cases in the GDB test suite. The new test cases
that are part of this series all use it, with iterations using both
'on' and 'off' for all of the tests therein.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Track and fetch TLS module ids for MUSL and GLIBC
This commit adds, to solib-svr4.h and solib-svr4.c, functions
glibc_link_map_to_tls_module_id and musl_link_map_to_tls_module_id for
use with callers in a new file svr4-tls-tdep.c (which is not in this
commit). It adds a number of helper functions for implementing link
map to module id support.
It also renames existing function 'find_program_interpreter' to
'svr4_find_program_interpreter' and makes it visible to other source
files within GDB. It will be used in the libc sniffing code in
svr4-tls-tdep.c in a later commit in this series. The libc sniffer is
needed in order to know which link map to module id function to call
as the method for determining module ids differs between libc /
dynamic linker implementations. These details are discussed in
comments in the patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24548
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31563 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Allow TLS access to work in gdb.server/no-thread-db.exp
The patches later in the series add GDB-internal TLS support for
certain targets. This commit updates the "print foo" test in
gdb.server/no-thread-db.exp to accept either a TLS failure (when
libthread_db isn't available) or printing the correct answer, which
will occur when GDB's internal TLS address resolution can be used.
I'm making this change prior to the commits which actually add
the GDB-internal TLS support in order to avoid tripping regression
testers.
Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Kevin Buettner [Thu, 24 Apr 2025 04:39:28 +0000 (21:39 -0700)]
Don't attempt to find TLS address when target has no registers
This commit fixes two bugs, one of which is Bug 25807, which occurs
when target_translate_tls_address() is called from
language_defn::read_var_value in findvar.c. I found it while testing on
aarch64; it turned a KFAIL for gdb.threads/tls.exp: print a_thread_local
into a FAIL due to a GDB internal error. Now, with this commit in place,
the KFAIL/FAIL turns into a PASS.
In addition to the existing test just noted, I've also added a test to
the new test case gdb.base/tls-nothreads.exp. It'll be tested, using
different scenarios, up to 8 times:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: after exit: print tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: after exit: print tls_tbss_1
There is a related problem that occurs when target_translate_tls_address
is called from find_minsym_type_and_address() in minsyms.c. It can be
observed when debugging a program without debugging symbols when the
program is not executing. I've written a new test for this, but it's
(also) included in the new test case gdb.base/tls-nothreads.exp, found
later in this series. Depending on the target, it can run up to 8
times using different scenarios. E.g., on aarch64, I'm seeing these
PASSes, all of which test this change:
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: default: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=false: stripped: after exit: print (int) tls_tbss_1
PASS: gdb.base/tls-nothreads.exp: pthreads-static: force_internal_tls=true: stripped: after exit: print (int) tls_tbss_1
In an earlier version of this commit (v4), I was checking whether the
target has registers in language_defn::read_var_value in findvar.c and
in find_minsym_type_and_address in minsyms.c, printing suitable error
messages in each case. In his review of this commit for the v4
series, Tom Tromey asked whether it would be better to do this check
in target_translate_tls_address. I had considered doing that for the
v4 (and earlier) series, but I wanted to print slightly different
messages at each check. Also, read_var_value in findvar.c was already
printing a message in some cases and I had arranged for the later
check in that function to match the original message.
However, while I had added a target-has-registers check at two of the
call sites for target_translate_tls_address, I hadn't added it at the
third call site which is in dwarf_expr_context::execute_stack_op() in
dwarf2/expr.c. I believe that in most cases, this is handled by the
early check in language_defn::read_var_value...
else if (sym_need == SYMBOL_NEEDS_REGISTERS && !target_has_registers ())
error (_("Cannot read `%s' without registers"), var->print_name ());
...but it's entirely possible that dwarf_expr_context::execute_stack_op()
might get called in some other context. So it makes sense to do the
target-has-registers check for that case too. And rather than add yet
another check at that call site, I decided that moving the check and
error message to target_translate_tls_address makes sense.
I had to make the error messages that it prints somewhat more generic.
In particular, when called from language_defn::read_var_value, the
message printed by target_translate_tls_address no longer matches the
earlier message that could be printed (as shown above). That meant
that the test cases which check for this message, gdb.threads/tls.exp,
and gdb.base/tls-nothreads.exp had to be adjusted to account for the
new message. Also, I think it's valuable to the user to know (if
possible) the name of the variable that caused the error, so I've
added an optional parameter to target_translate_tls_address, providing
the name of the variable, if it's known. Therefore, the message
that's printed when the target-has-registers test fails is one of the
following:
When the TLS variable isn't known (due to being called from
dwarf_expr_context::execute_stack_op):
"Cannot translate TLS address without registers"
When the TLS variable is known (from either of the other two call sites
for target_translate_tls_address):
"Cannot find address of TLS symbol `%s' without registers"
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25807 Tested-By: Luis Machado <luis.machado@arm.com> Approved-By: Luis Machado <luis.machado@arm.com>
Andrew Burgess [Thu, 9 Nov 2023 15:28:49 +0000 (15:28 +0000)]
gdb: add remote argument passing unit tests
This commit adds some remote argument passing unit tests. There are
not many tests right now -- there are known bugs in the remote
argument passing mechanism (see PR gdb/28392) -- but some simple cases
are covered here, and I plan to add additional tests once I've fixed
more of the problems with the existing argument handling code.
The tests take an inferior argument string, this is the string that
GDB would carry around as inferior::m_args. This string is then split
using gdb::remote_args::split, this gives a vector of strings, these
are the strings that are passed over the remote protocol. These split
strings are validated as part of the test.
The split strings are then combined using gdb::remote_args::join which
gives the inferior argument string that gdbserver will use, this is
held in server.cc as program_args, this joined string is then checked
as part of the test.
There are no changes to GDB's behaviour as part of this commit, other
than adding the new tests which can be run with:
(gdb) maintenance selftest remote-args
Running selftest remote-args.
Ran 1 unit tests, 0 failed
Andrew Burgess [Thu, 9 Nov 2023 14:47:34 +0000 (14:47 +0000)]
gdb: move remote arg splitting and joining into gdbsupport/
This is a refactoring commit. When passing inferior arguments to
gdbserver we have two actions that need to be performed, splitting and
joining.
On the GDB side, we take the inferior arguments, a single string, and
split the string into a list of individual arguments. These are then
sent to gdbserver over the remote protocol.
On the gdbserver side we receive the list of individual arguments and
join these back together into a single inferior argument string.
In the next commit I plan to add some unit testing for this remote
argument passing process. Ideally, for unit testing, we need the code
being tested to be located in some easily callable function, rather
than being inline at the site of use.
So in this commit I propose to move the splitting and joining logic
out into a separate file, we can then use this within GDB and
gdbserver when passing arguments between GDB and gdbserver, but we can
also call the same functions for some unit testing.
In this commit I'm not adding the unit tests, they will be added next,
so for now there should be no user visible changes after this commit.
gas: sframe: fix handling of .cfi_def_cfa_register
Fix PR gas/32879 sframe: Assembler internal error when translating
cfi_def_cfa_register
As per the documentation, .cfi_def_cfa_register modifies a rule for
computing CFA; the register is updated, but the offset remains the same.
While translating .cfi_def_cfa_register into SFrame context, we use the
information from last translated FRE to set the CFA offset. However,
there may be cases when the last translated FRE is empty. Use last FRE
only if available.
Andrew Burgess [Wed, 23 Apr 2025 09:22:32 +0000 (10:22 +0100)]
gdb/python: keyword arguments for gdb.Color.escape_sequence
GDB's Python documentation does make it clear that keywords arguments
are supported for functions that take 2 or more arguments. The
documentation makes no promise for keyword argument support on
functions that only take a single argument.
That said, I'm a fan of keyword arguments, I think they help document
the code, and make intentions clearer, even for single argument
functions.
As I'm changing gdb.Color anyway (see previous commit), I'd like to
add keyword argument support to gdb.Color.escape_sequence, even though
this is a single argument method. This should be harmless for anyone
who doesn't want to use keywords, but adds the option for those of us
that do.
I've also removed a redundant check that the 'self' argument was a
gdb.Color object; Python already ensures this is the case.
And I have folded the check that the single argument is a bool into
the gdb_PyArg_ParseTupleAndKeywords call, this means that the error
message will include the incorrect type name now, which should make
debugging issues easier.
Tests have been extended to cover both cases -- it appears the
incorrect argument type error was not previously tested, so it is
now.
Andrew Burgess [Wed, 23 Apr 2025 08:48:11 +0000 (09:48 +0100)]
gdb/doc: tweaks to documentation for gdb.Color
While reading through the documentation for the new gdb.Color class I
spotted a couple of things which I thought could be improved:
* I replaced @code{Color} with @code{gdb.Color}. Most of the other
classes are referenced with the 'gdb.' prefix, so this makes
gdb.Color consistent. Including the 'gdb.' prefix makes it far
easier to search the documentation to find relevant content. And
finally, my understanding is that usually in Python code, the
class would be written as 'gdb.Color' unless the user specifically
pulls 'Color' into the current scope using 'from gdb import
Color'.
* Replace 'colorspace' with 'color space'. There was already a use
of the two word form in the documentation (for gdb.Color), so this
just makes things consistent.
* Removed use of @var on two @defun lines. No other @defun lines
use @var, so the use of @var here was making the output
inconsistent, e.g. in the 'info' output, @var causes the string to
be capitalised.
* Rename the 'color-space' argument to 'color_space' for
Color.__init__. In the next commit I plan to add Python keyword
argument support to this function, which means the argument name
needs to be a valid keyword (i.e. must not contain the '-'
character).
* Added a pointer to where the @samp{COLORSPACE_} constants can be
found. These constants are referenced before they are defined in
the documentation, which is fine, but I think it is a good idea to
let the user know where the constants can be found when we first
reference them.
* Remove use of 'self' for the Color.escape_sequence documentation.
There are a few functions that do include 'self' as an argument (I
think this is a mistake) but the vast majority don't. I think not
including 'self' is the better approach; a user wouldn't be
expected to explicitly pass 'self', this is done automatically by
Python as a result of calling the method on an object. So I've
removed the reference to 'self' from this method.
Approved-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 22 Apr 2025 22:01:58 +0000 (23:01 +0100)]
gdb/python: don't use PyObject_IsInstance in py-unwind.c
I've been reviewing all uses of PyObject_IsInstance, and I believe
that the use of PyObject_IsInstance in py-unwind.c is not entirely
correct. The use of PyObject_IsInstance is in this code in
frame_unwind_python::sniff:
if (PyObject_IsInstance (pyo_unwind_info,
(PyObject *) &unwind_info_object_type) <= 0)
error (_("A Unwinder should return gdb.UnwindInfo instance."));
The problem is that PyObject_IsInstance can return -1 to indicate an
error, in which case a Python error will have been set. Now, the
above code appears to handle this case, it checks for '<= 0', however,
frame_unwind_python::sniff has this near the start:
gdbpy_enter enter_py (gdbarch);
And looking in python.c at 'gdbpy_enter::~gdbpy_enter ()', you'll
notice that if an error is set then the error is printed, but also, we
get a warning about an unhandled Python exception. Clearly, all
exceptions should have been handled by the time the gdbpy_enter
destructor is called.
I've added a test as part of this commit that exposes this problem,
the current output is:
(gdb) backtrace
Python Exception <class 'RuntimeError'>: error in Blah.__class__
warning: internal error: Unhandled Python exception
Python Exception <class 'gdb.error'>: A Unwinder should return gdb.UnwindInfo instance.
#0 corrupt_frame_inner () at /home/andrew/projects/binutils-gdb/build.dev-g/gdb/testsuite/../../../src.dev-g/gdb/test>
(gdb)
An additional observation is that we use PyObject_IsInstance to check
that the return value is a gdb.UnwindInfo, or a sub-class. However,
gdb.UnwindInfo lacks the Py_TPFLAGS_BASETYPE flag, and so cannot be
sub-classed. As such, PyObject_IsInstance is not really needed, we
could use PyObject_TypeCheck instead. The PyObject_TypeCheck function
only returns 0 or 1, there is no -1 error case. Switching to
PyObject_TypeCheck then, fixes the above problem.
There's a new test that exposes the problems that originally existed.
Andrew Burgess [Tue, 22 Apr 2025 20:43:43 +0000 (21:43 +0100)]
gdb/python: don't use PyObject_IsInstance in py-registers.c
In python/py-registers.c we make use of PyObject_IsInstance. The
PyObject_IsInstance can return -1 for an error, 0 for false, or 1 for
true.
In py-registers.c we treat the return value from PyObject_IsInstance
as a boolean, which means both -1 and 1 will be treated as true.
If PyObject_IsInstance returns -1 for an error, this will be treated
as true, we will then invoke undefined behaviour as the pyo_reg_id
object will be treated as a gdb.RegisterDescriptor, even though it
might not be.
I noticed that the gdb.RegisterDescriptor class does not have the
Py_TPFLAGS_BASETYPE flag, and therefore cannot be inherited from. As
such, using PyObject_IsInstance is not necessary, we can use
PyObject_TypeCheck instead. The PyObject_TypeCheck function only
returns 0 or 1, so we don't need to worry about the error case.
Because it runs so many variations, the test
gdb.dwarf2/macro-source-path.exp takes about 2:40 minutes to run for me,
in a non-optimized build. These days I often run all tests under
gdb.dwarf2, as a sanity test for my changes, and so I often have to wait
for this test to complete.
Split the test, to allow it to complete faster when running the
testsuite in parallel. After this patch, running all the
gdb.dwarf2/macro-source-path-*.exp tests in parallel takes me about 1
minute. It's more that I would expect, I would expect the time to be
divided by nearly 5, but it's already better than what we have now.
Change-Id: I07e4e1f234cf57d9b0c1c027f08061615714a4d5 Acked-By: Tom de Vries <tdevries@suse.de>
Timur [Thu, 10 Apr 2025 11:55:19 +0000 (14:55 +0300)]
gdb: fix riscv record-full push
When I (Guinevere) pushed commit b9c7eed0c2409fc640129a38d80a2bf1212b464a I accidentally used an outdated
version of the patch. This current patch fixes the importation of that
patch based on the actually approved version instead.
Tom de Vries [Wed, 23 Apr 2025 17:10:22 +0000 (19:10 +0200)]
[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp
With a gdb 16.2 based package, I ran into:
...
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: input still accepted
interrupt
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: interrupt
set var do_wait=0
(gdb) PASS: gdb.base/bg-execution-repeat.exp: c 1&: set var do_wait=0
continue&
Cannot execute this command while the selected thread is running.
(gdb)
Program received signal SIGINT, Interrupt.
PASS: gdb.base/bg-execution-repeat.exp: c 1&: continue&
0x00007ffff7cf1503 in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6
FAIL: gdb.base/bg-execution-repeat.exp: c 1&: breakpoint hit 2 (timeout)
...
Fix this by waiting for "Program received signal SIGINT, Interrupt" after
issuing the interrupt command.
Andrew Burgess [Tue, 22 Apr 2025 18:56:13 +0000 (19:56 +0100)]
gdb/python: don't use PyObject_IsInstance in gdbpy_is_color
The gdbpy_is_color function uses PyObject_IsInstance, and converts the
return from PyObject_IsInstance to a bool.
Unfortunately, PyObject_IsInstance can return -1, 0, or 1, for error,
failure, or success respectively. When converting to a bool both -1
and 1 will convert to true.
Additionally, when PyObject_IsInstance returns -1 an error will be
set.
What this means is that, if gdbpy_is_color is called with a non
gdb.Color object, and the PyObject_IsInstance check raises an error,
then (a) GDB will continue as if the object is a gdb.Color object,
which is likely going to invoke undefined behaviour, see
gdbpy_get_color for example, and (b) when GDB eventually returns to
the Python interpreter, due to an error being set, we'll see:
Python Exception <class 'SystemError'>: PyEval_EvalFrameEx returned a result with an error set
Error occurred in Python: PyEval_EvalFrameEx returned a result with an error set
However, after the previous commit, gdb.Color can no longer be
sub-classed, this means that fixing the above problems is easy, we can
replace the PyObject_IsInstance check with a PyObject_TypeCheck, the
PyObject_TypeCheck function only returns 0 or 1, there's no -1 error
case.
It's also worth noting that PyObject_TypeCheck is the function that is
more commonly used within GDB's Python API implementation, include the
py-color.c use there were only 4 PyObject_IsInstance uses. Of the
remaining 3, 2 are fine, and one other (in py-disasm.c) is also
wrong. I'll address that in a separate patch.
There's also a new test included which exposes the above issue.
Andrew Burgess [Tue, 22 Apr 2025 17:01:07 +0000 (18:01 +0100)]
gdb/python: remove Py_TPFLAGS_BASETYPE from gdb.Color
Remove the Py_TPFLAGS_BASETYPE flag from the gdb.Color type. This
effectively makes gdb.Color final; users can no longer create classes
that inherit from gdb.Color.
Right now I cannot think of any cases where inheritance would be
needed over composition for a simple type like gdb.Color. If I'm
wrong, then it's easy to add Py_TPFLAGS_BASETYPE back in later, this
would be an extension of the API. But it's much harder to remove the
flag later as that might break existing user code (note: there has
been no release of GDB yet that includes the gdb.Color type).
Introducing this restriction makes the next commit easier.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Tue, 22 Apr 2025 20:31:02 +0000 (21:31 +0100)]
gdb/python: stop using PyObject_IsInstance in py-disasm.c
The PyObject_IsInstance function can return -1 for errors, 0 to
indicate false, and 1 to indicate true.
I noticed in python/py-disasm.c that we treat the result of
PyObject_IsInstance as a bool. This means that if PyObject_IsInstance
returns -1, then this will be treated as true. The consequence of
this is that we will invoke undefined behaviour by treating the result
from the _print_insn call as if it was a DisassemblerResult object,
even though PyObject_IsInstance raised an error, and the result might
not be of the required type.
I could fix this by taking the -1 result into account, however,
gdb.DisassemblerResult cannot be sub-classed, the type doesn't have
the Py_TPFLAGS_BASETYPE flag. As such, we can switch to using
PyObject_TypeCheck instead, which only return 0 or 1, with no error
case.
I have also taken the opportunity to improve the error message emitted
if the result has the wrong type. Better error message make debugging
issues easier.
I've added a test which exposes the problem when using
PyObject_IsInstance, and I've updated the existing test for the
improved error message.
Commit b9c7eed0c2409fc640129a38d80a2bf1212b464a recently introduced
a build failure, because the file gdb/riscv-canonicalize-syscall-gen.c
hasn't been added to the ALL_64_TARGET_OBS variable in the makefile,
leading to a linker issue. This commit fixes that.
Also, turns out, the new file was slightly outdated, as the gdb_old_mmap
syscall has been renamed to gdb_sys_old_mmap in commit 432eca4113d5748ad284a068873455f9962b44fe. This commit also fixes that
on the generated file itself, to quickly fix the build. A followup
commit will fix the python file responsible for generating the .c file.
Guinevere Larsen [Wed, 26 Mar 2025 14:14:52 +0000 (11:14 -0300)]
GDB: Introduce "info linker-namespaces" command
Continuing to improve GDB's ability to debug linker namespaces, this
commit adds the command "info linker- namespaces". The command is
similar to "info sharedlibrary" but focused on improved readability
when the inferior has multiple linker namespaces active. This command
can be used in 2 different ways, with or without an argument.
When called without argument, the command will print the number of
namespaces, and for each active namespace, it's identifier, how many
libraries are loaded in it, and all the libraries (in a similar table to
what "info sharedlibrary" shows). As an example, this is what GDB's
output could look like:
(gdb) info linker-namespaces
There are 2 linker namespaces loaded
There are 3 libraries loaded in linker namespace [[0]]
Displaying libraries for linker namespace [[0]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6
0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
There are 4 libraries loaded in linker namespace [[1]]
Displaying libraries for linker namespace [[1]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7fb9000 0x00007ffff7fbe000 Yes gdb.base/dlmopen-ns-ids/dlmopen-lib.so
0x00007ffff7bc4000 0x00007ffff7caa000 Yes (*) /lib64/libm.so.6
0x00007ffff79d1000 0x00007ffff7bc4000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
When called with an argument, the argument must be a namespace
identifier (either with or without the square brackets decorators). In
this situation, the command will truncate the output to only show the
relevant information for the requested namespace. For example:
(gdb) info linker-namespaces 0
There are 3 libraries loaded in linker namespace [[0]]
Displaying libraries for linker namespace [[0]]:
From To Syms Read Shared Object Library
0x00007ffff7fc6000 0x00007ffff7fff000 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7ebc000 0x00007ffff7fa2000 Yes (*) /lib64/libm.so.6
0x00007ffff7cc9000 0x00007ffff7ebc000 Yes (*) /lib64/libc.so.6
(*): Shared library is missing debugging information.
The test gdb.base/dlmopen-ns-id.exp has been extended to test this new
command. Because some gcc and glibc defaults can change between
systems, we are not guaranteed to always have libc and libm loaded in a
namespace, so we can't guarantee the number of libraries, but the range
of the result is 2, so we can still check for glaring issues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Kevin Buettner <kevinb@redhat.com>
Guinevere Larsen [Tue, 25 Mar 2025 20:27:49 +0000 (17:27 -0300)]
gdb: factor out printing a table of solibs for info sharedlibrary
The next patch will add a new command that will print libraries in a
manner very similar to the existing "info sharedlibrary" command. To
make that patch simpler to review, this commit does the bulk of
refactoring work, since it ends up being a non-trivial diff to review.
No functional changes are expected after this commit.
Guinevere Larsen [Fri, 21 Mar 2025 19:35:07 +0000 (16:35 -0300)]
gdb: add convenience variables around linker namespace debugging
This commit adds 2 simple built-in convenience variables to help users
debug an inferior with multiple linker namespaces. The first is
$_active_linker_namespaces, which just counts how many namespaces have SOs
loaded onto them. The second is $_current_linker_namespace, and it tracks
which namespace the current location in the inferior belongs to.
This commit also introduces a test ensuring that we track namespaces
correctly, and that a user can use the $_current_linker_namespace
variable to set a conditional breakpoint, while linespec changes aren't
finalized to make it more convenient.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-by: Kevin Buettner <kevinb@redhat.com>
Timur [Tue, 18 Mar 2025 18:49:44 +0000 (21:49 +0300)]
This commit adds record full support for rv64gc instruction set
It includes changes to the following files:
- gdb/riscv-linux-tdep.c, gdb/riscv-linux-tdep.h: adds facilities to record
syscalls.
- gdb/riscv-tdep.c, gdb/riscv-tdep.h: adds facilities to record execution of
rv64gc instructions.
- gdb/configure.tgt: adds new files for compilation.
- gdb/testsuite/lib/gdb.exp: enables testing of full record mode for RISC-V
targets.
- gdb/syscalls/riscv-canonicalize-syscall-gen.py: a script to generate
function that canonicalizes RISC-V syscall. This script can simplify support
for syscalls on rv32 and rv64 system (currently support only for rv64). To
use this script you need to pass a path to a file with syscalls description
from riscv-glibc (example is in the help message). The script produces a
mapping from syscall names to gdb_syscall enum.
- gdb/riscv-canonicalize-syscall.c: the file generated by the previous script.
- gdb/doc/gdb.texinfo: notification that record mode is enabled in RISC-V.
- gdb/NEWS: notification of new functionality.
Approved-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom de Vries [Wed, 23 Apr 2025 09:02:53 +0000 (11:02 +0200)]
[gdb/testsuite] Add selftest disassemble-s390x
In commit a98a6fa2d8e ("s390: Add arch15 instructions"), support for
new instructions was added to libopcodes, but the added tests only exercise
this for gas.
Add a unit test disassemble-s390x that checks gdb's ability to
disassemble one of these instructions:
...
$ gdb -q -batch -ex "maint selftest -v disassemble-s390x"
Running selftest disassemble-s390x.
0xb9 0x68 0x00 0x03 -> clzg %r0,%r3
Ran 1 unit tests, 0 failed
...
Alan Modra [Wed, 23 Apr 2025 01:20:18 +0000 (10:50 +0930)]
string merge section map output
This fixes an inconsistency in the linker map file, where string merge
sections (other than the first) kept their sizes. String merge
sections of like entsize all are accounted in the fisrt string merge
section size.
* ldlang.c (print_input_section): Print SEC_EXCLUDE section size
as zero.
Tom Tromey [Wed, 19 Mar 2025 20:47:29 +0000 (14:47 -0600)]
Handle DWARF 5 separate debug sections
DWARF 5 standardized the .gnu_debugaltlink section that dwz emits in
multi-file mode. This is handled via some new forms, and a new
.debug_sup section.
This patch adds support for this to gdb. It is largely
straightforward, I think, though one oddity is that I chose not to
have this code search the system build-id directories for the
supplementary file. My feeling was that, while it makes sense for a
distro to unify the build-id concept with the hash stored in the
.debug_sup section, there's no intrinsic need to do so.
This in turn means that a few tests -- for example those that test the
index cache -- will not work in this mode.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32808 Acked-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Sat, 22 Mar 2025 16:39:43 +0000 (10:39 -0600)]
Remove 'read' call from dwz_file::read_string
dwz_file::read_string calls 'read' on the section, but this isn't
needed as the sections have all been pre-read.
This patch makes this change, and refactors dwz_file a bit to make
this more obvious -- by making it clear that only the "static
constructor" can create a dwz_file.
Approved-By: Simon Marchi <simon.marchi@efficios.com> Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Andrew Burgess [Tue, 22 Apr 2025 18:45:57 +0000 (19:45 +0100)]
gdb/testsuite: fix incorrect comment in py-color.exp
There was a comment in gdb.python/py-color.exp that was probably left
over from a copy & paste, it incorrectly described what the test
script was testing.
Fixed in this commit.
There's no change in what is tested with this commit.
Andrew Burgess [Sat, 19 Apr 2025 21:33:32 +0000 (22:33 +0100)]
gdb/python: address some coding style issues in py-color.c
A few minor GNU/GDB coding style issues in py-color.c:
- Space after '&' reference operator in one place.
- Some excessive indentation on a couple of lines.
- Spaces after '!' logical negation operator.
- Using a pointer as a bool in a couple of places.
There should be no functional changes after this commit.
it was pointed out that I should use @samp{} around some text I was
adding to the documentation. However, the offending snippet of
documentation was something I copied from elsewhere in python.texi.
This commit fixes the original to use @samp{}.
has an unnecessary `Py_INCREF (self);` in gdb.Color.__init__. This
means that the reference count on all gdb.Color objects (that pass
through __init__) will be +1 from where they should normally be, and
this will stop the gdb.Color objects from being deallocated.
Andrew Burgess [Sat, 19 Apr 2025 13:41:17 +0000 (14:41 +0100)]
gdb/python: restructure the existing memory leak tests
We currently have two memory leak tests in gdb.python/ and there's a
lot of duplication between these two.
In the next commit I'd like to add yet another memory leak test, which
would mean a third set of scripts which duplicate the existing two.
And three is where I draw the line.
This commit factors out the core of the memory leak tests into a new
module gdb_leak_detector.py, which can then be imported by each
tests's Python file in order to make writing the memory leak tests
easier.
I've also added a helper function to lib/gdb-python.exp which captures
some of the common steps needed in the TCL file in order to run a
memory leak test.
Finally, I use this new infrastructure to rewrite the two existing
memory leak tests.
What I considered, but ultimately didn't do, is merge the two memory
leak tests into a single TCL script. I did consider this, and for the
existing tests this would be possible, but future tests might require
different enough setup that this might not be possible for all future
tests, and now that we have helper functions in a central location,
the each individual test is actually pretty small now, so leaving them
separate seemed OK.
There should be no change in what is actually being tested after this
commit.
This fixes a crash on Windows NT 4.0, where windows-nat failed dynamic loading
some Win32 functions and print a warning message with styled string, which
depends on ui-style regex. By using `compiled_regex` constructor, the regex is
guaranteed to be initialized before `_initialize_xxx` functions.
Alan Modra [Sun, 20 Apr 2025 23:33:52 +0000 (09:03 +0930)]
avoid bogus format-overflow error
Seen on x86_64-linux Ubuntu 24.04.2 using gcc-13.3.0 with
CFLAGS="-m32 -g -O2 -fsanitize=address,undefined"
In function ‘sprintf’,
inlined from ‘s_mri_for’ at gas/config/tc-m68k.c:6941:5:
/usr/include/bits/stdio2.h:30:10: error: null destination pointer [-Werror=format-overflow=]
30 | return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31 | __glibc_objsize (__s), __fmt,
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
32 | __va_arg_pack ());
| ~~~~~~~~~~~~~~~~~
Rewrite the code without sprintf, as in other parts of s_mri_for.
See also commit 760fb390fd4c and following commits.
Note that adding -D_FORTIFY_SOURCE=0 to CFLAGS (which is a good idea
when building with sanitizers) merely transforms the sprintf_chk error
here into one regarding plain sprintf.
Alan Modra [Sat, 19 Apr 2025 05:12:23 +0000 (14:42 +0930)]
bfd_check_format_matches error paths
Tidy early out errors which didn't free matching_vector. Don't
bfd_preserve_restore if we get to err_ret from the first
bfd_preserve_save, which might fail from a memory allocation leaving
preserve.marker NULL. Also take bfd_lock a little earlier before
modifying abfd->format to simplify error return path from a lock
failure.
Simon Marchi [Thu, 17 Apr 2025 19:37:26 +0000 (15:37 -0400)]
gdb/dwarf: make some more functions methods of cutu_reader
These are only used by cutu_reader, so make them methods of cutu_reader.
This makes it a bit more obvious in which context this code is called.
lookup_dwo_unit_in_dwp can't be made a method of cutu_reader, as it is
used in another context (lookup_dwp_signatured_type /
lookup_signatured_type), which happens during CU expansion.
Change-Id: Ic62c3119dd6ec198411768323aaf640ed165f51b Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 17 Apr 2025 19:37:25 +0000 (15:37 -0400)]
gdb/dwarf: look up .dwp file ahead of time
get_dwp_file lazily looks for a .dwp file for the given objfile. It is
called by indexing workers, when a cutu_reader object looks for a DWO
file. It is called with the "dwo_lock" held, meaning that the first
worker to get there will do the work, while the others will wait at the
lock.
I'm trying to reduce the time where this lock is taken and do other
refactorings to make it easier to reason about the DWARF reader code.
Moving the lookup of the .dwp file ahead, before we start parallelizing
work, helps makes things simpler, because we can then assume everywhere
else that we have already checked for a .dwp file.
Put the call to open_and_init_dwp_file in dwarf2_has_info, right next to
where we look up .dwz files. I used the same try-catch pattern as for
the .dwz file lookup.
Change-Id: I615da85f62a66d752607f0dbe9f0372dfa04b86b Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Thu, 17 Apr 2025 19:37:20 +0000 (15:37 -0400)]
gdb/dwarf: remove dwarf2_section_info::get_size
The comment over dwarf2_section_info::get_size says:
In other cases, you must call this function, because for compressed
sections the size field is not set correctly until the section has
been read
From what I can see (while debugging a test case compiled with -gz on
Linux), that's not true. For compressed sections, bfd_section_size
returns the uncompressed size. asection::size contains the uncompressed
size while asection::compressed_size contains the compressed size:
(top-gdb) p sec
$13 = (asection *) 0x521000119778
(top-gdb) p sec.compressed_size
$14 = 6191
(top-gdb) p sec.size
$15 = 12116
I therefore propose to remove dwarf2_section_info::get_size, as it
appears that reading in the section is orthogonal to knowing its size.
If the assumption above is false, it would be nice to document in which
case it's false.
I checked the callers, and I don't think that we need to add any
dwarf2_section_info::read calls to compensate for the fact that get_size
used to do it.
Change-Id: I428571e532301d49f1d8242d687e1fcb819b75c1 Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Sat, 19 Apr 2025 17:33:12 +0000 (11:33 -0600)]
Remove some obsolete comments from ada-varobj.c
I noticed a few spots in ada-varobj.c that refer to calling xfree,
where the type in question has changed to std::string. This patch
removes these obsolete comments.
Alan Modra [Tue, 15 Apr 2025 21:42:46 +0000 (07:12 +0930)]
loongarch gas resolving constant expressions
The test added in commit 4fe96ddaf614 results in an asan complaint:
loongarch-parse.y:225:16: runtime error: left shift of negative value -1
To avoid the complaint, perform left shifts as unsigned (which gives
the same result on 2's complement machines). Do the same for
addition, subtraction and multiplication. Furthermore, warn on
divide/modulus by zero.
Tom de Vries [Thu, 17 Apr 2025 15:57:29 +0000 (17:57 +0200)]
[gdb/testsuite] Don't run to main in gdb.cp/cplusfuncs.exp
After building gdb with -fsanitize=threads, and running test-case
gdb.cp/cplusfuncs.exp, I run into a single timeout:
...
FAIL: gdb.cp/cplusfuncs.exp: info function operator=( (timeout)
...
and the test-case takes 2m33s to finish.
This is due to expanding CUs from libstdc++.
After de-installing package libstdc++6-debuginfo, the timeout disappears and
testing time goes down to 9 seconds.
Fix this by not running to main, which brings testing time down to 3 seconds.
With a gdb built without -fsanitize=threads, testing time goes down from 11
seconds to less than 1 second.
Tom Tromey [Tue, 15 Apr 2025 18:29:50 +0000 (12:29 -0600)]
Clean up value_struct_elt_bitpos
value_struct_elt_bitpos is weird: it takes an in/out value parameter,
and it takes an error string parameter. However, it only has a single
caller, which never uses the "out" value.
I think it was done this way to mimic value_struct_elt. However,
value_struct_elt is pretty ugly and I don't think it's worth
imitating.
This patch cleans up value_struct_elt_bitpos a bit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Yury Khrustalev [Thu, 27 Mar 2025 16:48:24 +0000 (16:48 +0000)]
aarch64: ld: Fix scanning of GNU properties for AARCH64_FEATURE_1_AND
Fixes [1]. Previously iteration over GNU properties of an input file
could stop before reaching GNU_PROPERTY_AARCH64_FEATURE_1_AND which
would result in incorrect inference of properties of the output file.
In the particular use case described in [1], the memory seal property
GNU_PROPERTY_MEMORY_SEAL with number 3, if present in the input file,
prevented reading information from GNU_PROPERTY_AARCH64_FEATURE_1_AND
property due to filtering by property number.
Simon Marchi [Fri, 11 Apr 2025 15:08:06 +0000 (11:08 -0400)]
gdb: fix bugs in gdb/copyright.py, make it use glob patterns
gdb/copyright.py currently changes some files that it shouldn't:
- despite having a `gnulib/import` entry in EXCLUDE_LIST, it does
change the files under that directory
- it is missing `sim/Makefile.in`
Change the exclude list logic to use glob patterns. This makes it
easier to specify exclusions of full directories or files by basename,
while simplifying the code.
Merge EXCLUDE_LIST and NOT_FSF_LIST, since there's no fundamental reason
to keep them separate (they are treated identically). I kept the
comment that explains that some files are excluded due to not being
FSF-licensed.
Merge EXCLUDE_ALL_LIST in EXCLUDE_LIST, converting the entries to glob
patterns that match everywhere in the tree (e.g. `**/configure`).
Tested by running the script on the parent commit of d01e823438c7
("Update copyright dates to include 2025") and diff'ing the result with d01e823438c7. The only differences are:
- the files that we don't want to modify (gnulib/import and
sim/Makefile.in)
- the files that need to be modified by hand
Running the script on latest master produces no diff.
Simon Marchi [Fri, 11 Apr 2025 15:08:05 +0000 (11:08 -0400)]
gdb: make typing strict in gdb/copyright.py
Add `pyright: strict` at the top of the file, then adjust the fallouts.
This annotation is understood by pyright, and thus any IDE using pyright
behind the scenes (VSCode and probably others).
I presume that any GDB developer running this script is using a recent
enough version of Python, so specify the type annotations using the
actual types when possible (e.g. `list[str]` instead of
`typing.List[str]`). I believe this required Python 3.9.
Tom de Vries [Wed, 16 Apr 2025 15:39:41 +0000 (17:39 +0200)]
[gdb/testsuite] Fix another timeout in gdb.base/bg-execution-repeat.exp
With test-case gdb.base/bg-execution-repeat.exp, occasionally I run into a
timeout:
...
(gdb) c 1&
Will stop next time breakpoint 1 is reached. Continuing.
(gdb) PASS: $exp: c 1&: c 1&
Breakpoint 2, foo () at bg-execution-repeat.c:23
23 return 0; /* set break here */
PASS: $exp: c 1&: breakpoint hit 1
Will stop next time breakpoint 2 is reached. Continuing.
(gdb) PASS: $exp: c 1&: repeat bg command
print 1
$1 = 1
(gdb) PASS: $exp: c 1&: input still accepted
interrupt
(gdb) PASS: $exp: c 1&: interrupt
Program received signal SIGINT, Interrupt.
foo () at bg-execution-repeat.c:24
24 }
PASS: $exp: c 1&: interrupt received
set var do_wait=0
(gdb) PASS: $exp: c 1&: set var do_wait=0
continue&
Continuing.
(gdb) PASS: $exp: c 1&: continue&
FAIL: $exp: c 1&: breakpoint hit 2 (timeout)
...
I can reproduce it reliably by adding a "sleep (1)" before the "do_wait = 1"
in the .c file.
The timeout happens as follows:
- with the inferior stopped at main, gdb continues (command c 1&)
- the inferior hits the breakpoint at foo
- gdb continues (using the repeat command functionality)
- the inferior is interrupted
- inferior variable do_wait gets set to 0. The assumption here is that the
inferior has progressed enough that do_wait is set to 1 at that point, but
that happens not to be the case. Consequently, this has no effect.
- gdb continues
- the inferior sets do_wait to 1
- the inferior enters the wait function, and wait for do_wait to become 0,
which never happens.
Fix this by moving the "do_wait = 1" to before the first call to foo.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Tom de Vries [Tue, 15 Apr 2025 14:59:32 +0000 (16:59 +0200)]
[gdb/ada] Fix gdb.ada/overloads.exp on s390x
On s390x-linux, with test-case gdb.ada/overloads.exp and gcc 7.5.0 I run into:
...
(gdb) print Oload(CA)^M
Could not find a match for oload^M
(gdb) FAIL: $exp: print Oload(CA)
...
The mismatch happens here in ada_type_match:
...
return ftype->code () == atype->code ();
...
with:
...
(gdb) p ftype->code ()
$3 = TYPE_CODE_TYPEDEF
(gdb) p atype->code ()
$4 = TYPE_CODE_ARRAY
...
At the start of ada_type_match, typedefs are skipped:
...
ftype = ada_check_typedef (ftype);
atype = ada_check_typedef (atype);
...
but immediately after this, refs are skipped:
...
if (ftype->code () == TYPE_CODE_REF)
ftype = ftype->target_type ();
if (atype->code () == TYPE_CODE_REF)
atype = atype->target_type ();
...
which in this case makes ftype a typedef.
Fix this by using ada_check_typedef after skipping the refs as well.
Tested on x86_64-linux and s390x-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR ada/32409
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32409
Simon Marchi [Fri, 11 Apr 2025 20:38:04 +0000 (16:38 -0400)]
gdb/dwarf: skip type units in create_dwo_cus_hash_table
When compiling with -gsplit-dwarf -fdebug-types-section, DWARF 5
.debug_info.dwo sections may contain some type units:
$ llvm-dwarfdump -F -color a-test.dwo | head -n 5
a-test.dwo: file format elf64-x86-64
.debug_info.dwo contents:
0x00000000: Type Unit: length = 0x000008a0, format = DWARF32, version = 0x0005, unit_type = DW_UT_split_type, abbr_offset = 0x0000, addr_size = 0x08, name = 'vector<int, std::allocator<int> >', type_signature = 0xb499dcf29e2928c4, type_offset = 0x0023 (next unit at 0x000008a4)
In this case, create_dwo_cus_hash_table wrongly creates a dwo_unit for
it and adds it to dwo_file::cus. create_dwo_debug_type_hash_table later
correctly creates a dwo_unit that it puts in dwo_file::tus.
Fix it by skipping anything that isn't a compile unit in
create_dwo_cus_hash_table. After this patch, the debug output of
create_dwo_cus_hash_table only shows one created dwo_unit, as we expect.
I couldn't find any user-visible problem related to this, I just noticed
it while debugging.
Change-Id: I7dddf766fe1164123b6702027b1beb56114f25b1 Reviewed-By: Tom de Vries <tdevries@suse.de>
projects / thirdparty / binutils-gdb.git / log
