Tom de Vries [Sat, 5 Jul 2025 11:29:53 +0000 (13:29 +0200)]
[gdb/tdep] Fix selftest scoped_mmap on freebsd
On x86_64-freebsd, I run into:
...
$ gdb -q -batch -ex "maint selftest scoped_mmap"
Running selftest scoped_mmap.
Self test failed: self-test failed at scoped_mmap-selftests.c:50
Failures:
scoped_mmap
Ran 1 unit tests, 1 failed
...
The problem is that this call:
...
::scoped_mmap smmap (nullptr, sysconf (_SC_PAGESIZE), PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, 0, 0);
...
returns MAP_FAILED and sets errno to EINVAL because the argument fd == 0.
If MAP_ANONYMOUS is used, fd == -1 should be used on freebsd. On linux, fd is
ignored but -1 is recommended for portability.
Tom de Vries [Sat, 5 Jul 2025 11:29:53 +0000 (13:29 +0200)]
[gdb/tdep] Fix doc string of kvm pcb/proc command
On x86_64-freebsd, I ran into:
...
$ gdb -q -batch -ex "maint selftest help_doc_invariants"
Running selftest help_doc_invariants.
help doc broken invariant: command 'kvm pcb' help doc first line is not \
terminated with a '.' character
Self test failed: self-test failed at command-def-selftests.c:120
Andrew Burgess [Mon, 23 Jun 2025 15:32:28 +0000 (16:32 +0100)]
gdb: create gdb.sum/gdb.log summary after using check-all-boards
Use the contrib/dg-extract-results.sh script to create a gdb.sum and
gdb.log summary after running the check-all-boards make target.
Having the results from all the boards merged into a single file
isn't (maybe) the most useful, but it isn't a bad thing. However, the
great thing about merge the results is that the totals are also
merged.
The 'check-all-boards' recipe can then extract these totals, just as
we do for the normal 'check' recipe, this makes is much easier to
spot if there are any unexpected failures when using
'check-all-boards'.
Pietro Monteiro [Sat, 5 Jul 2025 01:13:13 +0000 (21:13 -0400)]
sim: configury: fix obsolete macros
Running `autoreconf -vf -Wall' in the sim directory shows errors about the use
of obsolete macros. This patch fix the issues with macros used or defined in
the sim directory. However, it doesn't fix all warnings. There's 1 autoconf
warning from `config/pkg.m4', and many automake warnings about target
shadowing. It cuts a lot of the noise down and makes an upgrade to
autoconf 2.71+ easier.
- Replace AC_CANONICAL_SYSTEM by AC_CANONICAL_TARGET
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fCANONICAL_005fSYSTEM-1997
- Replace AC_TRY_COMPILE by AC_COMPILE_IFELSE
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTRY_005fCOMPILE-2203
- Replace AC_ERROR by AC_MSG_ERROR
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fERROR-2034
- Remove AC_TYPE_SIGNAL and replace `RETSIGTYPE' by `void' in the source
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fTYPE_005fSIGNAL-2213
- Remove AC_STRUCT_ST_BLKSIZE, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fBLKSIZE-2176
- Remove AC_STRUCT_ST_RDEV, it's already covered by a AC_CHECK_MEMBERS call
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Obsolete-Macros.html#index-AC_005fSTRUCT_005fST_005fRDEV-2180
- Remove AC_STRUCT_ST_BLOCKS. It is not obsolete, but it's already covered by a
AC_CHECK_MEMBERS call.
- Replace deprecated C macros HAVE_ST_${MEMBER} by HAVE_STRUCT_STAT_ST_${MEMBER}
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/
Particular-Structures.html#index-AC_005fSTRUCT_005fST_005fBLOCKS-693
Jan Beulich [Fri, 4 Jul 2025 08:42:18 +0000 (10:42 +0200)]
gas: introduce .errif and .warnif
Rather than having people resort to indirect means to issue a certain
kind of diagnostic conditionally upon an expression which can (or
should) only be evaluated when all sections were sized and all symbols
had their final values established, provide directives to directly
achieve this.
Jan Beulich [Fri, 4 Jul 2025 08:41:34 +0000 (10:41 +0200)]
gas: add a means to programmatically determine the assembler version
It has been more than once that I would have wanted to have a way to
know the gas version in assembly sources, perhaps for use with .if. Add
such a pre-defined symbol, introducing the common pattern GAS(<symbol>)
for any such symbols. The use of parentheses is to keep the risk of
collisions with users' symbols as low as possible. (Possible future
arch-specific symbols may want to use GAS(<arch>:<symbol>).)
Similarly permit determining whether the assembler is a released
version. The exact value probably isn't of much use, it's more the
defined-ness that one might care about. Yet the symbol needs to have
some value anyway.
While by default pre-defined symbols won't be emitted to the symbol
table, introduce -emit-local-absolute to allow requesting this. Re-
purpose flag_strip_local_absolute to become tristate, with a negative
value indicating to also emit pre-defined symbols.
Jan Beulich [Fri, 4 Jul 2025 08:40:31 +0000 (10:40 +0200)]
cris/testsuite: don't use --em=
Using such abbreviations is fine when written on an interactive command
line by a human. In scripts and alike, doing so risks colliding with
later option additions, as is about to occur for gas: Shortly there'll
be --emit-local-absolute.
Simon Marchi [Thu, 3 Jul 2025 17:37:41 +0000 (13:37 -0400)]
gdb/linux-nat: initialize lwp_info::syscall_state
When running gdb.base/foll-fork-syscall.exp with a GDB built with UBSan,
I get:
/home/simark/src/binutils-gdb/gdb/linux-nat.c:1906:28: runtime error: load of value 3200171710, which is not a valid value for type 'target_waitkind'
ERROR: GDB process no longer exists
GDB process exited with wait status 3026417 exp9 0 1
UNRESOLVED: gdb.base/foll-fork-syscall.exp: follow-fork-mode=child: detach-on-fork=on: test_catch_syscall: continue to breakpoint after fork
The error happens here:
#0 __sanitizer::Die () at /usr/src/debug/gcc/gcc/libsanitizer/sanitizer_common/sanitizer_termination.cpp:50
#1 0x00007ffff600d8dd in __ubsan::__ubsan_handle_load_invalid_value_abort (Data=<optimized out>, Val=<optimized out>) at /usr/src/debug/gcc/gcc/libsanitizer/ubsan/ubsan_handlers.cpp:551
#2 0x00005555636d37b6 in linux_handle_syscall_trap (lp=0x7cdff1eb1b00, stopping=0) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:1906
#3 0x00005555636e0991 in linux_nat_filter_event (lwpid=3030627, status=1407) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3044
#4 0x00005555636e407f in linux_nat_wait_1 (ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3381
#5 0x00005555636e7795 in linux_nat_target::wait (this=0x5555704d35e0 <the_amd64_linux_nat_target>, ptid=..., ourstatus=0x7bfff0d6cf18, target_options=...) at /home/simark/src/binutils-gdb/gdb/linux-nat.c:3607
#6 0x000055556378fad2 in thread_db_target::wait (this=0x55556af42980 <the_thread_db_target>, ptid=..., ourstatus=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/linux-thread-db.c:1398
#7 0x0000555564811327 in target_wait (ptid=..., status=0x7bfff0d6cf18, options=...) at /home/simark/src/binutils-gdb/gdb/target.c:2593
I believe the problem is that lwp_info::syscall_state is never
initialized. Fix that by initializing it with TARGET_WAITKIND_IGNORE.
This is the value we use elsewhere when resetting this field to mean
"not stopped at a syscall".
Change-Id: I5b76c63d1466d6e63448fced03305fd5ca8294eb Approved-By: Tom Tromey <tom@tromey.com>
Yodel Eldar [Mon, 26 May 2025 15:12:19 +0000 (10:12 -0500)]
gdb/alpha: Redefine fpcr with fpcr_flags type
This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr.
For details on the floating-point control register (fpcr), please see
the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it
consists of a 64-bit bitfield with most bits reserved/unused. All but a
pair of the used bits are boolean flags; the exception, DYN_RM, is a
2-bit enum indicating the IEEE rounding mode and is defined as a
dyn_rm_enum type in the target description annex.
Yodel Eldar [Mon, 26 May 2025 15:12:18 +0000 (10:12 -0500)]
gdb/alpha: Add target description support
This commit adds target description support for Alpha.
The target description obviates the alpha_register_type and
alpha_register_name functions in alpha-tdep.c. Removal of
alpha_register_reggroup_p was considered but ultimately abandoned,
because the "info regs" command would no longer omit the zero, fpcr, and
unique registers from its output (they are neither vector nor float
types).
Register types in the target description annex match the types that the
alpha_register_type function returned.
The locally defined register_names array was moved out of
alpha_register_name and renamed to alpha_register_names as a static
global; calls to alpha_register_name have been replaced with direct
access of the array.
The patch follows the code pattern outlined in the following GDB
Internals Wiki entry:
Tom de Vries [Wed, 2 Jul 2025 16:05:11 +0000 (18:05 +0200)]
[gdb/testsuite] Use support_displaced_stepping in gdb.arch/amd64-disp-step-avx.exp
In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp
on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then
I found support_displaced_stepping, which seems more appropriate and
descriptive.
Fix this by requiring support_displaced_stepping instead.
Tom de Vries [Wed, 2 Jul 2025 06:14:03 +0000 (08:14 +0200)]
[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into:
...
(gdb) continue
Continuing.
Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35
35 nop
(gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end
...
This happens while executing this bit of the test-case:
...
# Turn "debug displaced" on to make sure a displaced step is actually
# executed, not an inline step.
gdb_test_no_output "set debug displaced on"
Tom Tromey [Fri, 13 Jun 2025 18:54:16 +0000 (12:54 -0600)]
Fix handling of terminal escape sequences in TUI
A user noticed that if the remote sends terminal escape sequences from
the "monitor" command, then these will not be correctly displayed when
in TUI mode.
I tracked this down to remote.c emitting one character at a time --
something the TUI output functions did not handle correctly.
I decided in the end to fix in this in the ui-file layer, because the
same bug seems to affect logging and, as is evidenced by the test case
in this patch, Python output in TUI mode.
The idea is simple: buffer escape sequences until they are either
complete or cannot possibly be recognized by gdb.
Regression tested on x86-64 Fedora 40.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126 Approved-By: Andrew Burgess <aburgess@redhat.com>
A SFrame NULL FRE template is used as NULL value in some but not all
instances to initialize unused elements of SFrame FRE pointer arrays of
fixed size. Additionally it is erroneously used as SFrame FRE template
for PLT GOT entries.
Define a separate SFrame FRE template for PLT GOT entries with the same
properties as the SFrame NULL FRE and use that for all PLT GOT entries.
Remove the SFrame NULL FRE template, as initialization of unused array
elements is not required, as demonstrated by the instances where it was
not done.
bfd/
* elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove.
(elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for
PLT GOT entries.
(elf_x86_64_sframe_non_lazy_plt,
elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused
FRE array elements with elf_x86_64_sframe_null_fre. Use
elf_x86_64_sframe_pltgot_fre1 for PLT GOT.
(elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use
elf_x86_64_sframe_pltgot_fre1 for PLT GOT.
Bruce McCulloch [Fri, 27 Jun 2025 16:21:52 +0000 (09:21 -0700)]
libctf: doc: add __float128 and SIMD vector classification to spec.
This patch adds two additional distinct types (__float128 and the SIMD
vector type generated from the vector_size attribute) to the umbrella of
two existing types (long double and array, respectively). These types
were previously invalid, producing CTF_K_UNKNOWN in the case of
__float128 or a float in the case of the SIMD vector. This patch will
cleanly allow these types to be represented more accurately without
breaking back-compat.
Signed-off-by: Bruce McCulloch <bruce.mcculloch@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Nick Alcock [Thu, 26 Jun 2025 14:47:25 +0000 (15:47 +0100)]
libctf: create: check the right root-visible flag when adding enumerands
The root-visible flag we're dealing with here is directly out of the dict,
not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT
or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero
otherwise. Fix the test.
Nick Alcock [Thu, 26 Jun 2025 14:45:31 +0000 (15:45 +0100)]
libctf: create: addition of non-root types should not return root types
If you add a non-root type to a dict, you should always get a new, unique
type ID back, even if a root-visible type with the same name already exists.
Unfortunately, if the root-visible type is a forward, and you're adding a
non-root-visible struct, union, or enum, the machinery to detect forwards
and promote them to the concrete type fires in this case and returns the
root-visible type! If this is an enum being inserted hidden because its
enumerands conflict with some other enum, this will lead to failure later
on: in any case, it's seriously counterintuitive to add a non-root- visible
type and get a root-visible one instead.
Fix this by checking the root-visible flag properly and only checking for
forwards if this type is root-visible. (This may lead to a certain degree
of proliferation of non-root-visible forwards: we can add a cleanup pass for
those later if needed.)
libctf/
* ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when
doing forward promotion.
(ctf_add_union_sized): Likewise.
(ctf_add_enum): Likewise.
Reviewed-by: Bruce McCulloch <bruce.mcculloch@oracle.com>
Alan Modra [Tue, 1 Jul 2025 13:05:07 +0000 (14:05 +0100)]
MIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16
In rela howtos these relocations should not be using
_bfd_mips_elf_got16_reloc. That special function is for extracting
addends from section contents, and only for that (ie. it doesn't
subtract gp). Make these rela howtos like the corresponding
R_MIPS_GOT16 rela howto.
WANG Xuerui [Mon, 16 Jun 2025 08:16:55 +0000 (16:16 +0800)]
RISC-V: [gprofng] Allow building gprofng without asm/hwprobe.h
The code is actually able to gracefully fallback if the syscall number
of riscv_hwprobe is not available at build time, but it still depended
on the <asm/hwprobe.h> header unconditionally. In certain environments
such as one of crosstool-NG's Canadian Cross build step (binutils for
host), or one with very outdated kernel headers, the header will not be
present, causing the build to fail.
While the relevant projects/environments should be fixed nevertheless,
a configure-time check for <asm/hwprobe.h> is helpful for fixing gprofng
builds with released versions of ct-ng etc.
Simon Marchi [Sat, 28 Jun 2025 12:08:33 +0000 (08:08 -0400)]
gdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPAT
When building without expat, we get a missing make_target_solib_ops
error:
/usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()':
/home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()'
Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT.
Tom de Vries [Sat, 28 Jun 2025 11:03:14 +0000 (13:03 +0200)]
[gdb/tdep] Add "maint set console-translation-mode <binary|text>" command
On MSYS2, say we record a brief gdb session using TERM=dumb script:
...
$ gdb -q
(gdb) print 1
$1 = 1
(gdb) q
...
When looking at the resulting typescript, we notice something odd:
...
$ gdb -q^M
(gdb) print 1^M
$1 = 1^M^M
(gdb) q^M
...
For some reason, we have "$1 = 1\r\r\n(gdb) ".
Looking at the documentation of _setmode [1], it mentions translation mode
_O_TEXT as a mode in which "\n" is translated into "\r\n" on output.
So, it looks like this translation happens twice.
Add a command "maint set console-translation-mode <binary|text>" command that
allows us to set the translation mode of stdout/stderr to binary, such that we
get instead:
...
$ gdb -q -ex "maint set console-translation-mode binary"^M
(gdb) print 1^M
$1 = 1^M
(gdb) q^M
...
Since we run into this in the testsuite, add
"maint set console-translation-mode binary" to INTERNAL_GDBFLAGS.
Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre
Muller.
Compared to that proposal, I dropped the name testsuite-mode, because the
behaviour is not specific to the testsuite.
Also I chose values binary/text instead of on/off because eventually there may
be other translation mode values that we need [4].
Co-Authored-By: Pierre Muller <muller@sourceware.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode
[2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html
[3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
[4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64,
I hit this warning converted to an error:
In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37:
/home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field]
64 | long m_start_space;
| ^
1 error generated.
gmake[2]: *** [Makefile:1973: maint.o] Error 1
I used the default compiler on this system:
$ c++ --version
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
Target: aarch64-unknown-freebsd14.3
Thread model: posix
InstalledDir: /usr/bin
The problem is that the only two places that use m_start_space are
guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with
it.
Build-tested on aarch64-unknown-freebsd14.3.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Thu, 26 Jun 2025 17:36:58 +0000 (13:36 -0400)]
gdb/solib: C++ify solib_ops
Convert solib_ops into an abstract base class (with abstract methods,
some of them with default implementations) and convert all the existing
solib_ops instances to solib_ops derived classes / implementations.
Prior to this patch, solib_ops is a structure holding function pointers,
of which there are only a handful of global instances (in the
`solib-*.c` files). When passing an `solib_ops *` around, it's a
pointer to one of these instances. After this patch, there are no more
global solib_ops instances. Instances are created as needed and stored
in struct program_space. These instances could eventually be made to
contain the program space-specific data, which is currently kept in
per-program space registries (I have some pending patches for that).
Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a
pointer to the appropriate solib_ops implementation for the gdbarch.
This is replaced with the `gdbarch_make_solib_ops` method, which returns
a new instance of the appropriate solib_ops implementation for this
gdbarch. This requires introducing some factory functions for the
various solib_ops implementation, to be used as `gdbarch_make_solib_ops`
callbacks. For instance:
The previous code is full of cases of tdep files copying some base
solib_ops implementation, and overriding one or more function pointer
(see ppc_linux_init_abi, for instance). I tried to convert all of this
is a class hierarchy. I like that it's now possible to get a good
static view of all the existing solib_ops variants. The hierarchy looks
like this:
The solib-svr4 code has per-arch specialization to provide a
link_map_offsets, containing the offsets of the interesting fields in
`struct link_map` on that particular architecture. Prior to this patch,
arches would set a callback returning the appropriate link_map_offsets
by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened
to set the gdbarch's so_ops to `&svr_so_ops`. I converted this to an
abstract virtual method of `struct svr4_solib_ops`, meaning that all
classes deriving from svr4_solib_ops must provide a method returning the
appropriate link_map_offsets for the architecture. I renamed
`set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`. This
function is still necessary because it also calls
set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for
that, we could get rid of it.
There is an instance of CRTP in mips-linux-tdep.c, because both
mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need
to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops
and linux_lp64_svr4_solib_ops), but they both want to override the
in_dynsym_resolve_code method with the same implementation.
The solib_ops::supports_namespaces method is new: the support for
namespaces was previously predicated by the presence or absence of a
find_solib_ns method. It now needs to be explicit.
There is a new progspace::release_solib_ops method, which is only needed
for rocm_solib_ops. For the moment, rocm_solib_ops replaces and wraps
the existing svr4_solib_ops instance, in order to combine the results of
the two. The plan is to have a subsequent patch to allow program spaces to have
multiple solib_ops, removing the need for release_solib_ops.
Speaking of rocm_solib_ops: it previously overrode only a few methods by
copying svr4_solib_ops and overwriting some function pointers. Now, it
needs to implement all the methods that svr4_solib_ops implements, in
order to forward the call. Otherwise, the default solib_ops method
would be called, hiding the svr4_solib_ops implementation. Again, this
can be removed once we have support for multiple solib_ops in a
program_space.
There is also a small change in how rocm_solib_ops is activated. Prior
to this patch, it's done at the end of rocm_update_solib_list. Since it
overrides the function pointer in the static svr4_solib_ops, and then
overwrites the host gdbarch, so_ops field, it's something that happens
only once. After the patch though, we need to set rocm_solib_ops in all
the program spaces that appear. We do this in
rocm_solib_target_inferior_created and in the new
rocm_solib_target_inferior_execd. After this, I will explore doing a
change where rocm_solib_ops is only set when we detect the ROCm runtime
is loaded.
Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9 Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Thu, 26 Jun 2025 17:36:06 +0000 (13:36 -0400)]
gdb/progspace: add solib_ops pointer in program_space
The subsequent C++ification patch in this series will allocate one
instance of solib_ops per program space. That instance will be held in
struct program_space. As a small step towards this, add an `solib_ops
*` field to `struct program_space`. This field represents the solib_ops
currently used to manage the solibs in that program space. Initialize
it with the result of `gdbarch_so_ops` in `post_create_inferior`, and
use it whenever we need to do some solib stuff, rather than using
`gdbarch_so_ops` directly.
The difficulty here is knowing when exactly to set and unset the solib
ops. What I have here passes the testsuite on Linux, but with more
testing we will probably discover more spots where it's needed.
The C++ification patch will turn this field into a unique pointer.
With this patch, the message we get when running "info
linker-namespaces" becomes always the same, so update the test in
gdb.base/dlmopen-ns-ids.exp.
Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Simon Marchi [Mon, 16 Jun 2025 19:33:02 +0000 (15:33 -0400)]
gdb/solib: use solib::ops for operations that concern a single solib
For operations that concern a single solib, use the solib_ops backlink
added in the previous patch (solib::ops), instead of using the solib_ops
from the gdbarch. This is a small / easy step towards not using
gdbarch_so_ops, which is necessary for the C++ification patch later in
this series.
There is no change in behavior expected.
Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Mon, 16 Jun 2025 19:33:01 +0000 (15:33 -0400)]
gdb/solib: add solib -> solib_ops backlink
The subsequent C++ification commit makes it so that one struct solib_ops
is instantiated for each program space. For some operations, it will
then become necessary to be able to get the right solib_ops instance
from a given solib. Add an solib -> solib_ops backlink for that.
Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4 Approved-By: Pedro Alves <pedro@palves.net>
Simon Marchi [Mon, 16 Jun 2025 19:32:59 +0000 (15:32 -0400)]
gdb/testsuite: check that "info shared" and "info linker-namespaces" before running don't crash
While writing my solib_ops C++ification series, I broke this, and it
didn't seem to be caught by the testsuite. Add a test for those.
The exact message for "info linker-namespaces" varies depending on the
solib_ops of the target architecture (whether ops->num_active_namespaces
is nullptr or not). For now, just accept any message (a crash will
still be caught). A later patch in this series will make the message
consistent and update this test.
Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683 Approved-By: Pedro Alves <pedro@palves.net>
gdb: linux-namespaces: enter user namespace when appropriate
added a new test gdb.base/user-namespace-attach.exp. It has been
reported that this test will sometimes fail, like this:
(gdb) attach 184732
Attaching to process 184732
warning: process 184732 is a zombie - the process has already terminated
ptrace: Operation not permitted.
(gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior
the test tries to run the 'unshare' application. Sometimes though,
the application is present, but the set of flags used is not
supported (maybe due to restrictions on the local machine), so we see
behaviour like this:
Handle this case by first running 'unshare' with the same flags, but
using '/bin/true', if this fails then assume the flags are not
supported, and skip the test.
Tom Tromey [Thu, 22 May 2025 17:54:16 +0000 (11:54 -0600)]
Change file initialization to use INIT_GDB_FILE macro
This patch introduces a new macro, INIT_GDB_FILE. This is used to
replace the current "_initialize_" idiom when introducing a per-file
initialization function. That is, rather than write:
The macro handles both the declaration and definition of the function.
The point of this approach is that it makes it harder to accidentally
cause an initializer to be omitted; see commit 2711e475 ("Ensure
cooked_index_entry self-tests are run"). Specifically, the regexp now
used by make-init-c seems harder to trick.
New in v2: un-did some erroneous changes made by the script.
The bulk of this patch was written by script.
Regression tested on x86-64 Fedora 41.
aarch64: Add supports for FEAT_PoPS feature and DC instructions.
This patch add support for FEAT_PoPS feature which can be enabled
through +pops command line flag.
This patch also adds support for following DC instructions and the
spec can be found here [1].
1. "dc cigdvaps" enabled on passing +memtag+pops command line flags.
2. "dc civaps" enabled on passing +pops command line flag.
Andrew Burgess [Tue, 17 Jun 2025 16:39:36 +0000 (17:39 +0100)]
gdb: remove final m_stream->emit_style_escape calls from pager_file
After the last commit there were still a couple of calls to
m_stream->emit_style_escape in the pager_file class. As discussed in
the last commit, these are likely wrong, but I'd not been able to
produce any bugs because of them.
The reason why there are no bugs is that these calls are, I think,
entirely redundant. Consider this block:
if (m_wrap_column)
{
/* We are about to insert a newline at an historic
location in the WRAP_BUFFER. Before we do we want to
restore the default style. To know if we actually
need to insert an escape sequence we must restore the
current applied style to how it was at the WRAP_COLUMN
location. */
m_applied_style = m_wrap_style;
m_stream->emit_style_escape (ui_file_style ());
/* If we aren't actually wrapping, don't output
newline -- if chars_per_line is right, we
probably just overflowed anyway; if it's wrong,
let us keep going. */
m_stream->puts ("\n");
}
What we know (see previous commit) is that the call:
m_stream->emit_style_escape (ui_file_style ());
is dangerous as m_stream->m_applied_style is going to be out of sync
with its current state. Actually, m_stream->m_applied_style is likely
to be the default style as it is not updated elsewhere. So why does
this not cause problems?
Well, GDB's style output is always done in tightly scoped regions.
That means if we want to print some styled output, and then apply a
wrap point the code might look like this:
But, after printing 'some text', the style of gdb_stdout will have
returned to the default style.
My claim is that, whenever we encounter a wrap_here call, the stream
in question will _always_ have been returned to the default style.
This means that, in the block above, the call:
m_stream->emit_style_escape (ui_file_style ());
will never emit anything because it depends on a check against
m_stream->m_applied_style, which will always mean that the above call
does nothing. But that's OK. By chance, we'll have always placed the
stream into a default style state anyway, so no harm done.
Similarly, the other call:
/* Having finished inserting the wrapping we should
restore the style as it was at the WRAP_COLUMN. */
m_stream->emit_style_escape (m_wrap_style);
Tries to return m_stream to the state it was in at the point of the
wrap_here call. But, as described above, this will always be the
default style, so the above call will do nothing, but that just
happens to be exactly what we want!
So what does this commit do?
Well, I "fix" the above code by removing the
m_stream->emit_style_escape calls and replacing them with calls to
puts, passing in the escape sequence for the required style, but only
if the m_stream style as tracked by pager_file::m_stream_style
indicates this is needed.
Got the reasons given above, this should mean there is no change after
this patch. We still shouldn't be emitting any extra escape
sequences. But, should we ever manage to get into a state where we
call wrap_here with a stream in a style other than the default, then
this should mean things work as expected.
There should be no user visible changes after this commit.
Andrew Burgess [Mon, 16 Jun 2025 16:20:57 +0000 (17:20 +0100)]
gdb: styling fixes around and for the pagination prompt
This commit fixes a couple of issues relating to the pagination
prompt and styling. The pagination prompt is this one:
--Type <RET> for more, q to quit, c to continue without paging--
I did try to split this into multiple patches, based on the three
issues I describe below, but in the end, the fixes were all too
interconnected, so it ended up as one patch that makes two related,
but slightly different changes:
1. Within the pager_file class, relying on the m_applied_style
attribute of the wrapped m_stream, as is done when calling
m_stream->emit_style_escape, is not correct, so stop doing that, and
2. Failing to update m_applied_style within the pager_file class can
leave that attribute out of date, which can then lead to styling
errors later on, so ensure m_applied_style is always updated.
The problems I have seen are:
1. After quitting from a pagination prompt, the next command can
incorrectly style its output. This was reported as bug PR
gdb/31033, and is fixed by this commit.
2. The pagination prompt itself could be styled. The pagination
prompt should always be shown in the default style.
3. After continuing the output at a pagination prompt, GDB can fail
to restore the default style the next time the output (within the
same command) switches back to the default style.
There are tests for all these issues as part of this patch.
The pager_file class is a sub-class of wrapped_file, this means that a
pager_file is itself a ui_file, while it also manages a pointer to a
ui_file object (called m_stream). An instance of pager_file can be
installed as the gdb_stdout ui_file object.
Output sent to a pager_file is stored within an internal
buffer (called m_wrap_buffer) until we have a complete line, when the
content is flushed to the wrapped m_stream. If sufficient lines have
been written out then the pager_file will present the pagination
prompt and allow the user to continue viewing output, or quit the
current command.
As a pager_file is a ui_file, it has an m_applied_style member
variable.
The managed stream (m_stream) is also a ui_file, and so also has an
m_applied_style member variable.
In some places within the pager_file class we attempt to change the
current style of the m_stream using calls like this:
m_stream->emit_style_escape (style);
See pager_file::emit_style_escape, pager_file::prompt_for_continue,
and pager_file::puts. These calls will end up in
ui_file::emit_style_escape, which tries to skip emitting unnecessary
style escapes by checking if the requested style matches the current
m_applied_style value.
The m_applied_style value is updated by calls to the emit_style_escape
function.
The problem here is that most of the time pager_file doesn't change
the style of m_stream by calling m_stream->emit_style_escape. Most of
the time, style changes are performed by pager_file writing the escape
sequence into m_wrap_buffer, and then later flushing this buffer to
m_stream by calling m_stream->puts.
It has to be done this way. Calling m_stream->emit_style_escape
would, if it actually changed the style, immediately change the style
by emitting an escape sequence. But pager_file doesn't want that, it
wants the style change to happen later, when m_wrap_buffer is
flushed.
To avoid excessive style escape sequences being written into
m_wrap_buffer, the pager_file::m_applied_style performs a function
similar to the m_applied_style within m_stream, it tracks the current
style for the end of m_wrap_buffer, and only allows style escape
sequences to be emitted if the style is actually changing.
However, a consequence of this is the m_applied_style within m_stream,
is not updated, which means it will be out of sync with the actual
current style of m_stream. If we then try to make a call to
m_stream->emit_style_escape, if the style we are changing too happens
to match the out of date style in m_stream->m_applied_style, then the
style change will be ignored.
And this is indeed what we see in pager_file::prompt_for_continue with
the call:
m_stream->emit_style_escape (ui_file_style ());
As m_stream->m_applied_style is not being updated, it will always be
the default style, however m_stream itself might not actually be in
the default style. This call then will not emit an escape sequence as
the desired style matches the out of date m_applied_style.
The fix in this case is to call m_stream->puts directly, passing in
the escape sequence for the desired style. This will result in an
immediate change of style for m_stream, which fixes some of the
problems described above.
In fact, given that m_stream's m_applied_style is always going to be
out of sync, I think we should change all of the
m_stream->emit_style_escape calls to instead call m_stream->puts.
However, just changing to use puts doesn't fix all the problems.
I found that, if I run 'apropos time', then quit at the first
pagination prompt. If for the next command I run 'maintenance time' I
see the expected output:
"maintenance time" takes a numeric argument.
However, everything after the first double quote is given the command
name style rather than only styling the text between the double
quotes.
Here is GDB's stack while printing the above output:
#2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754
#3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73
#4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905
#5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945
#6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128
The interesting frames here are #3, in here `this` is the pager_file
for GDB's stdout, and this passes its m_applied_style to frame #2 as
the `in_style` argument.
If the m_applied_style is wrong, then frame #2 will believe that the
wrong style is currently in use as the default style, and so, after
printing 'maintenance time' GDB will switch back to the wrong style.
So the question is, why is pager_file::m_applied_style wrong?
In pager_file::prompt_for_continue, there is an attempt to switch back
to the default style using:
m_stream->emit_style_escape (ui_file_style ());
If this is changed to a puts call (see above) then this still leaves
pager_file::m_applied_style out of date.
The right fix in this case is, I think, to instead do this:
this->emit_style_escape (ui_file_style ());
this will update pager_file::m_applied_style, and also send the
default style to m_stream using a puts call.
While writing the tests I noticed that I was getting unnecessary style
reset sequences emitted.
The problem is that, around pagination, we don't really know what
style is currently applied to m_stream. The
pager_file::m_applied_style tracks the style at the end of
m_wrap_buffer, but this can run ahead of the current m_stream style.
For example, if the screen is currently full, such that the next
character of output will trigger the pagination prompt, if the next
call is actually to pager_file::emit_style_escape, then
pager_file::m_applied_style will be updated, but the style of m_stream
will remain unchanged. When the next character is written to
pager_file::puts then the pagination prompt will be presented, and GDB
will try to switch m_stream back to the default style. Whether an
escape is emitted or not will depend on the m_applied_style value,
which we know is different than the actual style of m_stream.
It is, after all, only when m_wrap_buffer is flushed to m_stream that
the style of m_stream actually change.
And so, this commit also adds pager_file::m_stream_style. This new
variable tracks the current style of m_stream. This really is a
replacement for m_stream's ui_file::m_applied_style, which is not
accessible from pager_file.
When content is flushed from m_wrap_buffer to m_stream then the
current value of pager_file::m_applied_style becomes the current style
of m_stream. But, when m_wrap_buffer is filling up, but before it is
flushed, then pager_file::m_applied_style can change, but
m_stream_style will remain unchanged.
Now in pager_file::emit_style_escape we are able to skip some of the
direct calls to m_stream->puts() used to emit style escapes.
After all this there are still a few calls to
m_stream->emit_style_escape(). These are all in the wrap_here support
code. I think that these calls are technically broken, but don't
actually cause any issues due to the way styling works in GDB. I
certainly haven't been able to trigger any bugs from these calls yet.
I plan to "fix" these in the next commit just for completeness.
Matthieu Longo [Thu, 17 Apr 2025 08:11:24 +0000 (09:11 +0100)]
readelf: invalid error message triggered when last tag is an empty string
Disclaimer: this issue cannot occur with Object Attributes v1 (OAv1) while
using the GNU binutils because a value of '\0' (empty string) for a tag
with a string value is considered as the default value for the attribute,
and consequently is eliminated by gas from the output object file during
the serialization.
An empty string is a valid value for a NTBS tag in both OAv1 and OAv2 [1]
cases. However, contrarily to OAv1, a OAv2 subsection can be required and
so, tags in this subsection might have to be present even if the value is
the default. To comply with this requirement, the OAv2 serializer won't
drop the default values.
In the case where a NTBS tag has the value '\0' and is last in the object
attributes section, the current code in readelf used for dumping the object
attributes incorrectly detects an overflow, and prints out an error message
for a corrupted string tag.
This patch fixes the detection of the overflow so that it now accept an
empty string in the last tag of the object attributes section.
It also fixes the previous tests for the empty NTBS case and the non-null
terminated string one. The fix was also tested in the context of OAv2's
patch series [1] where the issue was originally detected. No regression
was found.
Matthieu Longo [Fri, 20 Jun 2025 11:24:58 +0000 (12:24 +0100)]
arm testsuite: add two corner cases for EABI string attributes
The current testsuite for gas/readelf lacked two tests for EABI build
attributes:
- one when the final attribute is an empty string.
- one when the final attribute is a string missing the NULL terminator.
Those two issues cannot occur with Object Attributes v1 (OAv1) sections
created by the GNU binutils. Indeed a value of '\0' (empty string) for a
tag with a string value is considered as the default value for the
attribute, and consequently is eliminated by Gas from the output object
file during the serialization.
However, readelf should be able to process correctly files of an unknown
origin that could contain those two use cases.
This patch adds the two tests mentioned above. The first one is marked
as XFAIL because the empty string is not processed correctly by readelf
when it is in the last position. The second one passes, but simply print
out "[...]" without mentioning that the NTBS is corrupted.
A following patch will fix the bug in readelf, and will amend the newly
introduced tests.
Tom de Vries [Wed, 25 Jun 2025 07:39:30 +0000 (09:39 +0200)]
[gdb/testsuite] Fix gdb.base/infcall-failure.exp on freebsd
On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get:
...
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
0x0000000000400522 in func_segfault () at infcall-failure.c:24
24 return *p; /* Segfault here. */
Error in testing condition for breakpoint 2:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwind-on-signal on".
Evaluation of the expression containing the function
(func_segfault) will be abandoned.
When the function is done executing, GDB will silently stop.
(gdb) FAIL: $exp: target_async=on: target_non_stop=on: \
run_cond_hits_segfault_test: continue
...
The problem is that the regexp in the test-case doesn't expect the
"Address not mapped to object." bit.
Fix this by updating the regexp.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Tested on x86_64-freebsd and x86_64-linux.
Tom de Vries [Tue, 24 Jun 2025 15:17:38 +0000 (17:17 +0200)]
[gdb/testsuite] Make gdb.dap/log-message.exp more robust
PR testsuite/31831 reports the following failure in the
gdb.dap/log-message.exp test-case (formatted for readability):
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n"
},
"seq": 13
}
FAIL: $exp: logging output (checking body category)
...
for a gdb 14.2 based package.
The output event listed above is a result from the setBreakpoints request.
The test-case issues the setBreakpoints request and waits for the
corresponding response, but doesn't wait for the output event, and
consequently the output event is read by:
...
dap_wait_for_event_and_check "logging output" output \
{body category} console \
{body output} "got 23 - 23 = 0"
...
which triggers the failure.
I'm not able to reproduce this, but it looks worth fixing regardless.
We're fixing this on trunk though, and the output event looks different, and
there's one more output event:
...
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "No source file named log-message.c.\n"
},
"seq": 4
}
{ "type": "event",
"event": "output",
"body": {
"category": "stdout",
"output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n"
},
"seq": 5
}
...
Fix this by waiting for these two output events, making the test-case a bit
more robust.
It is possible that one or both of these output events will be read by
dap_check_request_and_response "set breakpoint", and in that case restashing
them (for which there's currently no infrastructure) would be an easy way of
handling this. But I haven't been able to trigger that, so I'm leaving that
for if and when it does.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831
Tom Tromey [Thu, 12 Jun 2025 16:48:25 +0000 (10:48 -0600)]
Allow DAP "threads" request when inferior is running
A user pointed out that DAP allows the "threads" request to work when
the inferior is running. This is documented in the overview, not the
specification.
While looking into this, I found a few other issues:
* The _thread_name function was not marked @in_gdb_thread.
This isn't very important but is still an oversight.
* DAP requires all threads to have a name -- the field is not optional
in the "Thread" type.
* There was no test examining events resulting from the inferior
printing to stdout.
Tom Tromey [Fri, 23 May 2025 23:48:30 +0000 (17:48 -0600)]
Use "MS" for .debug_str
I changed my system linker to 'mold', but then I saw some gdb test
failures. This patch fixes a subset of the failures.
dw2-strp.exp was failing, and investigating showed that there were two
.debug_str sections. I tracked this down to the .S file not using the
correct section flags.
This patch fixes this problem, plus the other instances I could find.
(Strangely, these did not all cause problems, however.) I also
changed the DWARF assembler to always use these flags for .debug_str.
Kito Cheng [Wed, 11 Jun 2025 08:33:49 +0000 (16:33 +0800)]
RISC-V: Support for unlabeled landing pad PLT generation
This patch adds support for generating unlabeled landing pad PLT entries
for the RISC-V architecture. Unlabeled landing pad will place a LPAD
instruction at the PLT entry and PLT header, also PLT header will have
few changes due to the offset is different from the original one.
Kito Cheng [Wed, 11 Jun 2025 08:33:46 +0000 (16:33 +0800)]
RISC-V: Refactor PLT generation
The goal of this refactor is to improve the possiblity of having
different PLT generation code for different RISC-V ABIs. The changes
include:
- Extract PLT generation logic into individual functions.
- Keep the PLT generation data in riscv_elf_link_hash_table.
In the following patches, we will use this framework to implement
different PLT.
Pawel Kupczak [Tue, 17 Jun 2025 14:08:15 +0000 (14:08 +0000)]
gdb: correct endbr64 instruction handling in amd64_analyze_prologue
Compilers can put a sequence aligning the stack at the entry of a
function. However with -fcf-protection enabled, "endbr64" is
generated before. Current implementation of amd64 prologue analyzer
first checks for stack alignment and then for "endbr64", which is not
correct. This behavior was introduced with patch "gdb: handle endbr64
instruction in amd64_analyze_prologue". In case both are generated,
prologue will not be skipped. This patch swaps the order so that
"endbr64" is checked first and adds a regression test. i386-tdep
implementation also already had those checked in the correct order,
that is stack alignment is after endbr64.
Given such source compiled with gcc 11.4.0 via:
gcc -O0 main.c -o main
int
main (int argc, char **argv)
{
foo (argc + 1);
return 1;
}
```
we get such function entry for foo (generated with objdump -d):
``` 0000000000001149 <foo>:
1149: f3 0f 1e fa endbr64
114d: 4c 8d 54 24 08 lea 0x8(%rsp),%r10
1152: 48 83 e4 c0 and $0xffffffffffffffc0,%rsp
1156: 41 ff 72 f8 push -0x8(%r10)
115a: 55 push %rbp
115b: 48 89 e5 mov %rsp,%rbp
115e: 41 52 push %r10
1160: 48 81 ec a8 00 00 00 sub $0xa8,%rsp
1167: 89 7d 8c mov %edi,-0x74(%rbp)
...
```
The 3 instructions following endbr64 align the stack. If we were to set
a breakpoint on foo, gdb would set it at function's entry:
```
(gdb) b foo
Breakpoint 1 at 0x1149
(gdb) r
...
Breakpoint 1, 0x0000555555555149 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
=> 0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: lea 0x8(%rsp),%r10
0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp
0x0000555555555156 <+13>: push -0x8(%r10)
0x000055555555515a <+17>: push %rbp
0x000055555555515b <+18>: mov %rsp,%rbp
0x000055555555515e <+21>: push %r10
0x0000555555555160 <+23>: sub $0xa8,%rsp
0x0000555555555167 <+30>: mov %edi,-0x74(%rbp)
...
```
With this patch fixing the order of checked instructions, gdb can
properly analyze the prologue:
```
(gdb) b foo
Breakpoint 1 at 0x115e
(gdb) r
...
Breakpoint 1, 0x000055555555515e in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: lea 0x8(%rsp),%r10
0x0000555555555152 <+9>: and $0xffffffffffffffc0,%rsp
0x0000555555555156 <+13>: push -0x8(%r10)
0x000055555555515a <+17>: push %rbp
0x000055555555515b <+18>: mov %rsp,%rbp
=> 0x000055555555515e <+21>: push %r10
0x0000555555555160 <+23>: sub $0xa8,%rsp
0x0000555555555167 <+30>: mov %edi,-0x74(%rbp)
...
```
Pawel Kupczak [Tue, 17 Jun 2025 14:08:14 +0000 (14:08 +0000)]
gdb: refactor amd64_analyze_prologue
Refactor amd64_analyze_prologue so it clearly reflects what is the order
of operations in the prologue that we expect to encounter, as is the
case for i386's implementation.
Andrew Burgess [Tue, 3 Jun 2025 13:26:50 +0000 (14:26 +0100)]
gdb/testsuite: use TESTS from make-check-all.sh
Update the make-check-all.sh script to use TESTS rather than passing
the test names within RUNTESTFLAGS. This addresses the following
issue:
I was running some tests like this:
make -C gdb check-all-boards TESTS="gdb.base/break*.exp"
And I was finding that I would get lots of DUPLICATE test results,
which is not what I expected.
What's happening here is that the 'make check-all-boards' rule runs
the 'make-check-all.sh' script, which then runs 'make check' with
various board files.
However, passing TESTS=... to the initial 'make check-all-boards'
command invocation automatically causes the TESTS value to be added to
the MAKEFLAGS environment variable, this is then picked up by the
later calls to 'make check'.
Now, in GDB's testfile/Makefile, we check for TESTS, and if this is
set, we expand the value and set `expanded_tests_or_none`. Otherwise,
if TESTS is not set, expanded_tests_or_none is left empty.
Finally, when handling 'make check', the value of
`expanded_tests_or_none` is passed through to dejagnu, along with the
RUNTESTFLAGS value.
What this means is that, when make-check-all.sh passes the test names
in the RUNTESTFLAGS, then dejagnu ends up seeing the list of tests
twice, once from RUNTESTFLAGS, and once from expanded_tests_or_none,
and this is why I was seeing duplicate testnames.
The easiest fix for the above is to have make-check-all.sh pass the
test names using TESTS="...", this will override the TESTS="..." value
already present in MAKEFLAGS, and means dejagnu will see the test
names just once.
Additionally, this is a start towards allowing parallel test running
from the make-check-all.sh script. Parallel test running only works
if the test names are passed in TESTS, and not in RUNTESTFLAGS.
Currently, in testsuite/Makefile, if RUNTESTFLAGS is not empty, then
we force single threaded test running. But with this change, at least
for the `local` board, we can now benefit from multi-threaded test
running, as this board has an empty RUNTESTFLAGS now. For the other
boards we'd need to set FORCE_PARALLEL in order to benefit from
parallel test running, but we'll need to double check that all the
board files actually support parallel test running first, so I'm
leaving that for another day.
gdb: use quoted filename completion for the shell command
which fixed the completion for the 'shell' command itself.
Like with the 'shell' command, we don't offer completions of command
names pulled from $PATH, we just offer filename completion, which is
often useful for arguments being passed to commands. Maybe in the
future we could add completion for command names too (for both 'pipe'
and the 'shell' command), but that is left for a future commit.
Benjamin Berg [Tue, 21 Mar 2023 12:01:26 +0000 (13:01 +0100)]
gdb: linux-namespaces: enter user namespace when appropriate
The use of user namespaces is required for normal users to use mount
namespaces. Consider trying this as an unprivileged user:
$ unshare --mount /bin/true
unshare: unshare failed: Operation not permitted
The problem here is that an unprivileged user doesn't have the
required permissions to create a new mount namespace. If, instead, we
do this:
$ unshare --mount --map-root-user /bin/true
then this will succeed. The new option causes unshare to create a
user namespace in which the unprivileged user is mapped to UID/GID 0,
and so gains all privileges (inside the namespace), the user is then
able to create the mount namespace as required.
So, how does this relate to GDB?
When a user attaches to a process running in a separate mount
namespace, GDB makes use of a separate helper process (see
linux_mntns_get_helper in nat/linux-namespaces.c), which will then use
the `setns` function to enter (or try to enter) the mount namespace of
the process GDB is attaching too. The helper process will then handle
file I/O requests received from GDB, and return the results back to
GDB, this allows GDB to access files within the mount namespace.
The problem here is that, switching to a mount namespace requires that
a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within
its user namespace (actually it's a little more complex, see 'man 2
setns'). Assuming GDB is running as an unprivileged user, then GDB
will not have the required permissions.
However, if GDB enters the user namespace that the `unshare` process
created, then the current user will be mapped to UID/GID 0, and will
have the required permissions.
And so, this patch extends linux_mntns_access_fs (in
nat/linux-namespace.c) to first try and switch to the user namespace
of the inferior before trying to switch to the mount namespace. If
the inferior does have a user namespace, and does have elevated
privileges within that namespace, then this first switch by GDB will
mean that the second step, into the mount namespace, will succeed.
If there is no user namespace, or the inferior doesn't have elevated
privileges within the user namespace, then the switch into the mount
namespace will fail, just as it currently does, and the user will need
to give elevated privileges to GDB via some other mechanism (e.g. run
as root).
I (Andrew Burgess) have made some cleanups to the code to comply with
GDB's coding standard, and the test is entirely mine. This commit
message is also entirely mine -- the original message was very terse
and required the reader to understand how the various namespaces
work and interact. The above is my attempt to document what I now
understand about the problem being fixed.
I've left the original author in place as the core of the GDB change
itself is largely as originally presented, but any inaccuracies in the
commit message, or problems with the test, are all mine.
Co-Authored-by: Andrew Burgess <aburgess@redhat.com>
gdb: attach to a process when the executable has been deleted
The above commit extended GDB for Linux, so that, of the executable
for a process had been deleted, GDB would instead try to use
/proc/PID/exe as the executable.
This worked by updating linux_proc_pid_to_exec_file to introduce the
/proc/PID/exe fallback. However, the result of
linux_proc_pid_to_exec_file is then passed to exec_file_find to
actually find the executable, and exec_file_find, will take into
account the sysroot. In addition, if GDB is attaching to a process in
a different MNT and/or PID namespace then the executable lookup is
done within that namespace.
This all means two things:
1. Just because linux_proc_pid_to_exec_file cannot see the
executable doesn't mean that GDB is actually going to fail to
find the executable, and
2. returning /proc/PID/exe isn't useful if we know GDB is then going
to look for this within a sysroot, or within some other
namespace (where PIDs might be different).
There was an initial attempt to fix this issue here:
This proposal addresses the issue in PR gdb/32955, which is all about
the namespace side of the problem. The fix in this original proposal
is to check the MNT namespace inside linux_proc_pid_to_exec_file, and
for the namespace problem this is fine. But we should also consider
the sysroot problem.
And for the sysroot problem, the fix cannot fully live inside
linux_proc_pid_to_exec_file, as linux_proc_pid_to_exec_file is shared
between GDB and gdbserver, and gdbserver has no sysroot.
And so, I propose a slightly bigger change.
Now, linux_proc_pid_to_exec_file takes a flag which indicates if
GDB (or gdbserver) will look for the inferior executable in the
local file system, where local means the same file system as GDB (or
gdbserver) is running in.
This local file system check is true if:
1. The MNT namespace of the inferior is the same as for GDB, and
2. for GDB only, the sysroot must either be empty, or 'target:'.
If the local file system check is false then GDB (or gdbserver) is
going to look elsewhere for the inferior executable, and so, falling
back to /proc/PID/exe should not be done, as GDB will end up looking
for this file in the sysroot, or within the alternative MNT
namespace (which in also likely to be a different PID namespace).
Now this is all a bit of a shame really. It would be nice if
linux_proc_pid_to_exec_file could return /proc/PID/exe in such a way
that exec_file_find would know that the file should NOT be looked for
in the sysroot, or in the alternative namespace. But fixing that
problem would be a much bigger change, so for now lets just disable
the /proc/PID/exe fallback for cases where it might not work.
For testing, the sysroot case is now tested.
I don't believe we have any alternative namespace testing. It would
certainly be interesting to add some, but I'm not proposing any with
this patch, so the code for checking the MNT namespace has been tested
manually by me, but isn't covered by a new test I'm adding here.
Author of the original fix is listed as co-author here. Credit for
identifying the original problem, and proposing a solution belongs to
them.
Andrew Burgess [Thu, 22 May 2025 13:29:49 +0000 (14:29 +0100)]
gdb: better warning when attaching, and executable is unknown
Currently, when attaching to a process, if the user hasn't told GDB
which executable they are going to be debugging, GDB will try to
figure out the executable from the running process.
There are two (for this patch) interesting places where this can fail,
both in exec_file_locate_attach.
First GDB calls target_pid_to_exec_file, this does target specific
"stuff" to find the name of the executable file. If this returns NULL
then GDB will give a warning and return.
After this we need to "find" the executable. This is where we apply
things like the sysroot in order to transform the executable path.
This is done by calling exec_file_find, and this too can return NULL
to indicate that the executable couldn't be found.
Currently, if exec_file_find returns NULL then GDB doesn't give a
warning, instead we push on and call try_open_exec_file passing in the
NULL pointer as the filename string. This has the effect of removing
the current executable from the current program space.
However, exec_file_locate_attach already checks there is no executable
attached to the current program space. If there was, then there would
be no need to try and lookup the executable from the running process.
So calling try_open_exec_file with a NULL string is, I claim,
pointless.
But worse, calling try_open_exec_file with a NULL string means that
GDB prints the message: "No executable file now.", which, while
correct, isn't (I think) very helpful. To me this message indicates
that we've moved from a state of having an executable to a state of
not having one, which isn't correct.
I think we should introduce a new warning in exec_file_locate_attach,
which is printed if the executable cannot be found.
So, before this patch GDB's output looked like this:
(gdb) attach 12345
Attaching to process 12345
No executable file now.
warning: Could not load vsyscall page because no executable was specified
0x00007f0978b94557 in ?? ()
(gdb)
After this patch the output now looks like this:
(gdb) attach 12345
Attaching to process 12345
No executable has been specified, and target executable /tmp/my-exec (deleted) could not be found. Try using the "file" command.
warning: Could not load vsyscall page because no executable was specified
0x00007f0978b94557 in ?? ()
(gdb)
This warning includes the name of the file that GDB was looking for,
and gives a hint that the 'file' command should be used to tell GDB
which executable is being debugged. Much better.
There's no test for this change in this commit. The next commit fixes
another (semi-related) bug, and includes a test that checks for this
warning string.
gdb: implement linux namespace support for fileio_lstat and vFile::lstat
The build failure looks like this:
../../src/gdbserver/hostio.cc: In function 'void handle_lstat(char*, int*)':
../../src/gdbserver/hostio.cc:544:63: error: cannot convert '_stat64*' to 'stat*'
544 | ret = the_target->multifs_lstat (hostio_fs_pid, filename, &st);
| ^~~
| |
| _stat64*
In file included from ./../../src/gdbserver/server.h:58,
from <command-line>:
./../../src/gdbserver/target.h:448:74: note: initializing argument 3 of 'virtual int process_stratum_target::multifs_lstat(int, const char*, stat*)'
448 | virtual int multifs_lstat (int pid, const char *filename, struct stat *sb);
| ~~~~~~~~~~~~~^~
The problem is that in sys/stat.h for mingw, 'stat' is #defined to
_stat64, but target.h doesn't include sys/stat.h, and so doesn't see
this #define.
However, target.h does, by luck, manages to see the actual definition
of 'struct stat', which isn't in sys/stat.h itself, but is in some
other header that just happens to be pulled in by chance.
As a result of all this, the declaration of
process_stratum_target::multifs_lstat in target.h uses 'struct stat'
for its argument type, while the call in hostio.cc, uses 'struct
_stat64' as its argument type, which causes the build error seen
above.
The fix is to include sys/stat.h in target.h so that the declaration's
argument type will change to 'struct _stat64' (via the #define).
Stafford Horne [Sun, 15 Jun 2025 04:15:40 +0000 (05:15 +0100)]
or1k: Fix disassembly for little-endian binaries
There are some OpenRISC CPUs that have their binaries stored in
little-endian format. Using objdump to disassemble these is
problematic, as some instructions fail to disassemble, for example:
It was found that the hash function was using the still little-endian
buffer to extract the opcode used for the hash lookup. This didn't work
as it was pulling the wrong hashcode causing instruction lookup to fail.
Fix the hash function by using the normalized/byte-swapped value instead
of the buffer.
aarch64: Support 2024 Debug Architecture system registers.
This patch adds support for following system registers and the spec
can be found here[1].
1. PMBSR_EL12, PMBSR_EL2, PMBSR_EL3, PMBMAR_EL1 depends on FEAT_SPE
and Armv9.5-A architecture and these are enabled by passing
-march=armv9.5-a+profile.
2. TRBSR_EL12, TRBSR_EL2, and TRBSR_EL3 depends Armv9.5-A architecture
and these are enabled by passing -march=armv9.5-a.
3. HFGITR2_EL2 depends on Armv8.8-A architecture and enabled by passing
-march=armv8.8-a.
Kirill Radkin [Tue, 3 Jun 2025 13:48:23 +0000 (16:48 +0300)]
gdbserver: Update require_int function to parse offset for pread packet
Currently gdbserver uses the require_int() function to parse the
requested offset (in vFile::pread packet and the like). This function
allows integers up to 0x7fffffff (to fit in 32-bit int), however the
offset (for the pread system call) has an off_t type which can be
larger than 32-bit.
This patch allows require_int() function to parse offset up to the
maximum value implied by the off_t type.
Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I3691bcc1ab1838c0db7f8b82d297d276a5419c8c
projects / thirdparty / binutils-gdb.git / log
