Simon Marchi [Fri, 25 Jul 2025 16:31:44 +0000 (12:31 -0400)]
gdb, gdbserver: update copyright years in copyright notices
The copyright notices printed by these programs still use year 2024.
Update to 2025.
It seems like a trivial patch to me, but I am posting it for review, in
case there's something wrong in the new-year process that caused them to
be missed, in which case we should address that too.
Change-Id: I7d9541bb154b8000e66cfead4e4228e33c49f18b Approved-by: Kevin Buettner <kevinb@redhat.com>
warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
This is visible when running this test:
$ make check TESTS="gdb.dwarf2/debug-names-duplicate-cu.exp" RUNTESTFLAGS="--target_board=cc-with-debug-names"
...
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/debug-names-duplicate-cu.exp ...
gdb compile failed, warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
...
=== gdb Summary ===
# of untested testcases 1
However, it's easy to miss because it only causes an "UNTESTED" to be
recorded, not a FAIL or UNRESOLVED. This is because the problem happens
while trying to create the .debug_names index, as part of the test case
compilation.
The problem is: when we bail out from using .debug_names because we
detect it is inconsistent with the units in .debug_info, we clear
per_bfd->all_units, to destroy all units previously created, before
proceeding to read the units with an index. However, we don't clear
per_bfd->num_{comp,type}_units. As a result, per_bfd->all_units
contains one unit, while per_bfd->num_comp_units is 2. Whenever we
clear per_bfd->all_units, we should also clear
per_bfd->num_{comp,type}_units.
While at it, move this logic inside a scoped object.
I added an assertion in finalize_all_units to verify that the size of
per_bfd->all_units equals per_bfd->num_comp_units +
per_bfd->num_type_units. This makes the problem (if omitting the fix)
visible when running gdb.dwarf2/debug-names-duplicate-cu.exp with the
unix (default) target board:
ERROR: Couldn't load debug-names-duplicate-cu into GDB (GDB internal error).
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type (GDB internal error)
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type, check type is valid
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 2
# of unresolved testcases 1
I considered changing the code to build a local vector of units first,
then move it in per_bfd->all_units on success, that would avoid having
to clean it up on error. I did not do it because it's a much larger
change, but we could consider it.
Change-Id: I49bcc0cb4b34aba3d882b27c8a93c168e8875c08 Approved-By: Tom Tromey <tom@tromey.com>
This reproduces with gcc 7, not with gcc 8 or later.
Fix this by throwing an error instead of asserting, getting us instead:
...
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2.2, A::func (this=$hex) at condbreak-multi-context.cc:31^M
31 void func () {}^M
(gdb) PASS: $exp: start_before=true: scenario_1: run until A::func
...
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
PR gdb/32012
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32012
Guinevere Larsen [Wed, 13 Aug 2025 13:01:52 +0000 (10:01 -0300)]
gdb: modernize get_frame_pc_if_available
The convenience function get_frame_pc_if_available would take a pointer
to a variable that should be set if available, and would return a
boolean indicating whether that action was successful or not.
Now that GDB supports C++17 features, this indirection of a pointer and
returning boolean is unnecessary, since the function can return an
optional, and code that calls it can check if the optional contains a
value.
This commit makes that modernization. It should have no visible
effects.
Tom de Vries [Thu, 14 Aug 2025 16:38:30 +0000 (18:38 +0200)]
[gdb/testsuite] Remove useless indentation in lib/tuiterm.exp
In lib/tuiterm.exp we have:
...
namespace eval Term {
variable ...
...
}
...
with everything within the namespace (which is basically the entire file)
indented, which wastes screen space and makes editing more involved.
We could maybe fix this by moving the "namespace eval Term" to tuiterm_env,
but I don't think it's a good idea to move it out of the file.
Another idea is to have the file include itself, wrapped in the namespace:
...
if { ![info exists Term::_in_namespace] } {
namespace eval Term {
# Read the rest of this file, wrapped in this namespace.
variable _in_namespace
set _in_namespace 1
source $::srcdir/lib/tuiterm.exp
unset _in_namespace
return
}
}
variable ...
...
but this was considered unnecessarily complex.
Fix this in the style of lib/ton.tcl and lib/completion-support.exp:
- only declare the variables in the namespace, and
- define the procs using a Term:: prefix.
As a side-effect, this works around an emacs bug that makes editing
lib/tuiterm.exp in its current form problematic because the auto-indentation
keeps removing required indentation of all but the first proc [1].
Guinevere Larsen [Wed, 21 Aug 2024 14:10:50 +0000 (11:10 -0300)]
gdb, configure: Add enable-binary-file-format option for configure
GDB has support for many binary file formats, some which might be very
unlikely to be found in some situations (such as the XCOFF format in
an x86 system). This commit introduces the option for a user to choose
which formats GDB will support at build configuration time.
This is especially useful to avoid possible security concerns with
readers that aren't expected to be used at all, as they are one of
the simplest vectors for an attacker to try and hit GDB with. This
change can also reduce the size of the final binary, if that is a
concern.
This commit adds a switch to the configure script allowing a user to
only enable selected file formats, called --enable-binary-file-formats.
The default behavior when the switch is omitted is to compile all file
formats, keeping the original behavior of the script. At the time of
this commit, the valid options for this option are: dbx, coff (which
includes coff-pe), xcoff, mips, elf, macho and all. All is treated
especially, activating all supported readers.
A few targets may require specific binary file format support, as they
directly call functions defined by the file reader. Specifically,
windows targets require coff support, and rs6000 aix and lynx178 targets
require xcoff support. Considering that those formats are the main - or
only - one available in those targets, I believe it makes sense to
re-enable those readers. If that happens, the script will emit the
following warning:
FOO is required to support one or more requested targets. Adding it
Users aren't able to force the disabling of those formats, since GDB
will not compile without those readers. Ideally we'd like to be able
to disable even those formats, in case a user wants to build GDB only
to examine remote files for example, but the current infrastructure
for the file format readers doesn't allow us to do it.
Mach-O and elf support are also dependent on BFD support being compiled
in. In case one of those was requested and BFD does not support them,
the following error is emitted:
FOO was requested, but BFD does not support it.
Finally, this configure switch is also printed by the "show
configuration" command in GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Indu Bhagat [Thu, 14 Aug 2025 16:08:31 +0000 (09:08 -0700)]
bfd: sframe: fix PR ld/33199
Fix PR ld/33199 SEGV in _bfd_x86_elf_create_sframe_plt
Currently, the selection for sframe_plt was not being done (and simply
set to NULL) for the case when !normal_target, causing SEGV on Solaris.
Initialize sframe_plt to init_table->sframe_lazy_plt when lazy_plt is
true, and NULL otherwise. This is in line with htab->non_lazy_plt being
set to NULL for !normal_target.
bfd/
PR ld/33199
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Setup sframe_plt for !normal_target.
Andrew Burgess [Fri, 25 Jul 2025 18:51:58 +0000 (19:51 +0100)]
bfd: support for NT_386_TLS notes
In a later commit I'd like to add support to GDB for including the
NT_386_TLS note in the core files that GDB creates (using 'gcore'
command).
To achieve this we need some standard boilerplate code added to bfd.
The only part of this patch which I think needs consideration is the
name I selected for the pseudo section to hold the note contents when
a core file is loaded. I chose '.reg-i386-tls'. The '.reg' prefix is
the standard used by most other pseudo sections, and the '-i386-tls'
suffix seemed to match the note name, though I added the 'i' to
'i386', instead of just using '.reg-386-tls'. I thought 'i386' seemed
clearer.
There's no test included here, but when I merge the NT_386_TLS
creation to GDB it will depend on this and act as a test. I plan to
post that work to the GDB list once this patch is merged.
H.J. Lu [Tue, 12 Aug 2025 14:37:57 +0000 (07:37 -0700)]
ld: Use stat to check if linker script appears multiple times
Use stat, instead of strcmp, to check if the same linker script file
appears multiple times for
$ ld -L... -T ././/script.t -T script.t ...
Although ././/script.t and script.t access the same file, but their
filenames are different. strcmp won't work here.
Copy gnulib/import/same-inode.h to include since the gnulib directory
isn't included in the binutils tarball.
include/
PR ld/24576
* same-inode.h: New file. Copied from gnulib/import/same-inode.h.
ld/
PR ld/24576
* ldfile.c: Include "same-inode.h".
(ldfile_find_command_file): Change the second argument from bool
to enum script_open_style. Check if the same linker script file
appears multiple times by using stat, instead using strcmp.
(ldfile_open_command_file_1): Don't check if the same linker
script file appears multiple times here.
* testsuite/ld-scripts/pr24576-1.d: Adjusted.
* testsuite/ld-scripts/pr24576-2.d: New.
* testsuite/ld-scripts/script.exp: Run pr24576-2.
Tom de Vries [Thu, 14 Aug 2025 13:49:20 +0000 (15:49 +0200)]
[gdb/testsuite] Disable CLI styling by default in Term::prepare_tui
On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to
match the output of the file command, for which I submitted a patch [1].
However, after switching to TERM=ansiw for bsd, I could no longer reproduce
the problem.
Investigation showed that the difference was caused by CLI styling.
A command:
...
(gdb) file <filename>
...
gives an output:
...
Reading symbols from <filename>...
(gdb)
...
On x86_64-linux, with CLI styling I get:
...
Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m...
...
After disabling CLI styling using "set style enabled off", I simply get:
...
Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main...
...
and run into the same failure as on x86_64-freebsd.
The extra csi sequence "^[[32m" causes an additional matching attempt in
Term::wait_for, and the way we're currently matching relies on this:
...
send_gdb "file [standard_output_file $testfile]\n"
gdb_assert { [Term::wait_for "Reading symbols from"] } "file command"
...
Make the TUI testsuite more stable and matching more simple by disabling CLI
styling by default, and:
- fix the resulting fallout in test-cases gdb.tui/main.exp and
gdb.tui/new-layout.exp, and
- re-enable CLI styling in the one test-case that needs it:
gdb.tui/tui-disasm-styling.exp.
Alan Modra [Wed, 13 Aug 2025 13:05:53 +0000 (22:35 +0930)]
Recognise ECOFF armap in bfd_slurp_armap
Recognise ECOFF archives and reject them so that the ecoff archive
support has a chance to handle the archive. Also use memcmp rather
than startswith (strncmp) as we know the string length.
* archive.c (bfd_slurp_armap): Recognize ECOFF armap. Use memcmp
to match names, and tidy buffer sizes.
Alan Modra [Sat, 9 Aug 2025 09:32:25 +0000 (19:02 +0930)]
objcopy/strip of IR files and is_strip_input
This tidies objcopy/strip handling of IR objects, in the process of
removing the unnecessary is_strip_input flag.
The first thing I noticed when looking at is_strip_input code was that
the abfd->my_archive test in bfd_check_format_matches meant that
plugins were disabled when reading archive elements. We can instead
disable plugins by setting bfd_no_plugin, so there doesn't seem to be
a need for is_strip_input in objcopy.c:copy_archive. This isn't
exactly the same, because bfd_no_plugin prevents the plugin target
recognising archive elements in the bfd_check_format_matches loop over
all targets as well as just the first !target_defaulted test. But
that turns out to be fine. IR code is handled in copy_archive as for
other unknown format files. In fact, the only need for the plugin
target when copying archives is when reading symbols for the archive
map. I've made that plain by moving the plugin target override and
commenting on why it is really needed.
So on to plain object files. Here, IR code is also copied unchanged,
so there doesn't seem a need for the plugin target there either. It
isn't quite so simple though, because the objcopy/strip code handling
object files wants to verify the format of the object file. Allowing
objcopy/strip to copy unknown format files would be a change in
behaviour (and results in mmix testsuite fails, ld-mmix/b-badfil1 and
others). However, always excluding the plugin target results in a
fail of tests added in commit c2729c37f10a. So I've enabled a plugin
format check only for files that are otherwise unrecognised, and
commented why this is done. I question the need to objcopy LLVM
bytecode files.
bfd/
* bfd.c (struct bfd<is_strip_input>): Delete.
* format.c (bfd_check_format_matches): Delete is_strip_input
special case code.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Don't set is_strip_input. Always
set bfd_plugin_no when reading elements. Enable plugins when
opening copied elements.
(check_format_object): Delete.
(copy_file): Don't enable plugin target here. Don't set
is_strip_input. Set bfd_plugin_no. Move bfd_core handling
code earlier to remove goto. Enable plugin for llvm bytecode.
Copy slim IR files as unknown objects.
Alan Modra [Tue, 12 Aug 2025 13:16:58 +0000 (22:46 +0930)]
Correct readelf thin archive test
If we have an existing archive, the test may fail due to it being the
wrong format. Also, downloading bintest.thin.a from a remote host
(before creating it!) is wrong.
* testsuite/binutils-all/readelf.exp (readelf_thin_archive_test):
Don't remote_download bintest.thin.a. Delete lib before
creating.
Tom de Vries [Thu, 14 Aug 2025 13:18:34 +0000 (15:18 +0200)]
[gdb/testsuite] Make prompt matching in Term::wait_for more strict
On x86_64-freebsd, I run into:
...
Box Dump (80 x 24) @ (0, 0):
0 (gdb) maint info screen
1 Number of characters gdb thinks are in a line is 90.
2 Number of characters readline reports are in a line is 89.
3 Number of characters curses thinks are in a line is 90.
4 Number of characters environment thinks are in a line is 90 (COLUMNS).
5 Number of lines gdb thinks are in a page is 40.
6 Number of lines readline reports are in a page is 40.
7 Number of lines curses thinks are in a page is 40.
8 Number of lines environment thinks are in a page is 40 (LINES).
9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column
10 .
11 (gdb) tui disable
12 (gdb) tui disable
13 (gdb) maint info screen
14
15
16
17
18
19
20
21
22
23
FAIL: gdb.tui/resize-2.exp: again: curses width 80
...
The problem is that the prompt matching in Term::wait for is not strict enough.
It will accept a line:
...
(gdb) foo
...
as long as the cursor is pointing just after the prompt, like so:
...
(gdb) foo
^
...
Tom de Vries [Thu, 14 Aug 2025 12:53:19 +0000 (14:53 +0200)]
[gdb/testsuite] Stop on main in gdb.gdb/{python-helper,selftest}.exp
With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into:
...
UNTESTED: gdb.gdb/selftest.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
UNTESTED: gdb.gdb/python-helper.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
...
I don't know why we're trying to stop in captured_main.
Stopping in main also works, and main is more likely to be present in an lto
build.
Fix this by using main instead.
This requires us to update the expected file name from main.c to gdb.c in
selftest_setup.
After doing so, we get:
...
XFAIL: gdb.gdb/selftest.exp: \
run until breakpoint at main (line numbers scrambled?)
XFAIL: gdb.gdb/python-helper.exp: \
run until breakpoint at main (line numbers scrambled?)
...
because main is reported to be in run-on-main-thread.c instead of gdb.c:
.
Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M
...
This is due to picking the last line entry for pc == 0x455e40 that has
is_stmt == true:
...
File name Line number Starting address View Stmt
gdb/gdb.c:
gdb.c 25 0x455e40 x
gdb.c 30 0x455e40 1 x
gdb/run-on-main-thread.c:
run-on-main-thread.c 116 0x455e40 2 x
run-on-main-thread.c 120 0x455e40 3 x
Tom de Vries [Thu, 14 Aug 2025 11:54:54 +0000 (13:54 +0200)]
[gdb/testsuite] Make ^C cancel i-search
PR cli/21690 reports the following: say we start gdb:
...
$ gdb -q
(gdb)
...
and press ^R for reverse-i-search:
...
(reverse-i-search)`':
...
Pressing the p key has the effect of showing both the pressed key and a
matching entry, which happens to be up:
...
(reverse-i-search)`p': up
...
Now we press ^C to cancel the search:
...
(reverse-i-search)`p': u❌️ Quit
(gdb)
...
and type "down".
We expected to get:
...
(gdb) down
...
but instead we get:
...
(failed reverse-i-search)`pdown':
...
So we're stuck in reverse-i-search, until we use the workaround of ^G.
The same problem happened with python [1], was reported upstream [2], and
fixed in cpython commit d6990d221b0 ("Issue #24266: Cancel history search mode
with Ctrl+C in Readline 7") using rl_callback_sigcleanup.
Fix this likewise in quit using rl_callback_sigcleanup, a new callback
function in readline 7.0:
...
i. rl_callback_sigcleanup: a new application function that can clean up and
unset any state set by readline's callback mode. Intended to be used
after a signal.
...
giving us instead:
...
$ gdb
(gdb) u❌️ Quit
(gdb) down
...
Remove the corresponding kfail in gdb.tui/pr30056.exp.
Since recently c.slli64, c.srai64, and c.srli64 have been removed from the
riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed
as hints,
https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093
So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to
assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai
when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as
aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with
0 immediate.
Passed rv32/64-elf/linux binutils testcases.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64,
c.srai64, and c.srli64 with 0 immediate as a hint.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/zca.d: Likewise.
opcodes/
PR 33216
* riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64,
and c.srli64 with 0 immediate as a hint.
Tom Tromey [Wed, 13 Aug 2025 18:08:59 +0000 (12:08 -0600)]
Remove cast from captured_main
captured_main takes a 'void *', but then immediately casts it to the
correct type. There's no reason for this any more, the caller passes
in the correct type. This patch cleans this up. Tested by
rebuilding.
Pietro Monteiro [Wed, 13 Aug 2025 01:12:50 +0000 (21:12 -0400)]
gnulib: Update obsolete autoconf macros
Remove AM_PROG_CC_STDC, the correct macro AC_PROG_CC is already being
used.
Update AC_OUTPUT (file list, [cmd list]) by adding the file list to
the previous AC_CONFIG_FILES and using AC_CONFIG_COMMANDS to output
the command list.
Tom de Vries [Tue, 12 Aug 2025 14:35:05 +0000 (16:35 +0200)]
[gdb/tdep] Handle M1 ldp in aarch64_stopped_data_address
In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice,
two adjacent 8-byte vars are written. For aarch64, we use a single stp
instruction for that.
If we do the same in function read_size8twice for two adjacent 8-byte var reads
using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
...
The same problem was observed for stp in PR tdep/29423, fixed by commit 9a03f218534 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64").
See that commit for an explanation of the hang.
That commit introduced max_access_size in aarch64_stopped_data_address:
...
The access size also can be larger than that of the watchpoint
itself. For instance, the access size of an stp instruction is 16.
So, if we use stp to store to address p, and set a watchpoint on
address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
RK3399 SOC). But it also can be p (observed on M1 SOC). Checking
for this situation introduces the possibility of false positives,
so we only do this for hw_write watchpoints. */
const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
...
If we say that hangs are worse than false positives, then we should also fix
this case.
Fix this by setting max_access_size to 16 for all watchpoint types.
Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Improve the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice:
- move the code into a proc
- use -wrap
- use $decimal more often
- don't use gdb_test_multiple $test $test
- add comments
- start test when entering write_size8twice function, instead of main
- finish test when leaving write_size8twice function, instead of main
- add insn in between:
- insn triggering watchpoint, and
- insn triggering breakpoint
to ensure that the watchpoint triggers before the breakpoint, and
add a comment explaining this.
Tom Tromey [Tue, 12 Aug 2025 13:13:26 +0000 (07:13 -0600)]
Avoid scopes.exp failure on certain architectures
A buildbot pointed out that my changes to gdb.dap/scopes.exp caused a
test failure. The new code iterates over all the registers, fetching
their children (when possible). The failure comes because this code
failed to consider that a register might have "indexed" children,
which I believe can occur when a register is vector-like.
This patch fixes the problem by arranging to fetch indexed children
when indicated.
Tom Tromey [Wed, 30 Jul 2025 14:30:49 +0000 (08:30 -0600)]
Emit DAPException when too many variable children are reqeusted
PR dap/33228 points out a failure that occurs when the DAP client
requests more children of a variable than actually exist. Currently,
gdb throws a somewhat confusing exception. This patch changes this
code to throw a DAPException instead, resulting in a more ordinary and
readable failure.
The spec seems to be silent on what to do in this case. I chose an
exception on the theory that it's easier to be strict now and lift the
restriction later (if needed) than vice versa.
Tom Tromey [Tue, 29 Jul 2025 13:48:21 +0000 (07:48 -0600)]
Do not allow DAP clients to dereference "void *"
While investigating a different bug, I noticed that the DAP code would
report a "void *"-typed register as having children -- however,
requesting the children of this register would fail.
The issue here is that a plain "void *" can't be dereferenced. This
patch changes the default visualizer to treat a "void *" as a scalar.
This adds a new test; but also arranges to examine all the returned
registers -- this was the first thing I attempted and it seemed
reasonable to have a test that double-checks that all the registers
really can be dereferenced as appropriate.
H.J. Lu [Fri, 8 Aug 2025 01:04:47 +0000 (18:04 -0700)]
x86: Treat protected symbols with indirect external access as local
If all external symbol accesses are indirect, we can treat protected
symbols as local since there will be no copy relocation for data and
external function pointer access will go through GOT, instead of PLT.
No PLT slot should be used for external function pointer in executable.
bfd/
PR ld/33260
* elfxx-x86.h (COPY_INPUT_RELOC_P): Treat protected symbols with
indirect external access as local.
Keith Seitz [Tue, 5 Aug 2025 17:44:48 +0000 (10:44 -0700)]
should_validate_memtags: Do not dereference references
should_validate_memtags uses value_as_address to evalute
whether an address for a value is tagged. The comments for
that function simply say, "Extract a value as a C pointer."
While that sounds innoncuous, that function calls coerce_array,
which will dereference any references. This is not what is
desired here.
This can be demonstrated on an MTE-enabled host, such as aarch64-
based Ampere (example taken from tests introduced in this patch):
(gdb) p b.get_foo ()
Could not validate memory tag: Value can't be converted to integer.
$2 = (const foo &) @0xffffffffed88: {m_a = 42}
While the command completes, gdb didn't actually attempt to
evaluate any memory tags.
Tom de Vries [Fri, 8 Aug 2025 11:51:00 +0000 (13:51 +0200)]
[gdb/testsuite] Fix gdb.tui/basic.exp for TERM=ansis
With test-case gdb.tui/basic.exp and TERM=ansis, I run into (with some logging
added):
...
status line: '<reverse:1><intensity:dim>exec No process (asm) In:
L?? PC: ?? <reverse:0><intensity:normal>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
The status window uses ncurses attribute standout, which can differ between
different terminal settings.
Tom de Vries [Fri, 8 Aug 2025 11:51:00 +0000 (13:51 +0200)]
[gdb/testsuite] Fix gdb.tui/main-2.exp for TERM=ansis
When running test-case gdb.tui/main-2.exp with TERM=ansis, I get:
...
screen line 6: 'B+><fg:black><intensity:bold> 21 <reverse:1><fg:default><intensity:normal> return 0;<reverse:0> '
FAIL: gdb.tui/main-2.exp: highlighted line in middle of source window
...
The test tries to check the highlighting of the source line, but also gets the
part with the line number, which makes it more complicated to parse.
Fix this by getting just the part with the source line:
...
screen line 6: '<reverse:1> return 0;<reverse:0> \
'
...
Tom de Vries [Fri, 8 Aug 2025 11:51:00 +0000 (13:51 +0200)]
[gdb/testsuite] Initial TERM=ansis support in tuiterm
While investigating using TERM=ansiw for freebsd, I also came across
TERM=ansis which unlike ansiw is present on both linux and freebsd.
Add initial support for TERM=ansi in tuiterm:
- handle ansis in Term::_have_bw
- add Term::_csi_x to support (well, ignore) DECREQTPARM
(Request Terminal Parameters)
This is sufficient to make the TUI testsuite pass on x86_64-freebsd.
The test-case gdb.tui/tui-layout-asm-short-prog.exp uses an assembly file
gdb.tui/tui-layout-asm-short-prog.S that it compiles using -nostdlib and
-nostartfiles.
However, on x86_64-linux the resulting executable still has dependencies on
libm and libc:
...
$ ldd outputs/gdb.tui/tui-layout-asm-short-prog/tui-layout-asm-short-prog
linux-vdso.so.1 (0x00007ffddf3ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8b13406000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8b13000000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8b1350f000)
...
due -lm being added by default_target_compile.
On x86_64-freebsd, using -nostdlib and -nostartfiles in combination with -lm
causes the compilation to fail.
Tom de Vries [Fri, 8 Aug 2025 10:57:01 +0000 (12:57 +0200)]
[gdb/testsuite] Fix gdb.base/exprs.exp for gdb build with byacc
On x86_64-freebsd, with test-case gdb.base/exprs.exp I get:
...
(gdb) print 23
yydebug: state 0, reading 257 (INT)
yydebug: state 0, shifting to state 1
yydebug: state 1, reducing by rule 94 (exp : INT)
yydebug: after reduction, shifting from state 0 to state 59
yydebug: state 59, reading 0 (end-of-file)
yydebug: state 59, reducing by rule 7 (exp1 : exp)
yydebug: after reduction, shifting from state 0 to state 60
yydebug: state 60, reducing by rule 1 (start : exp1)
yydebug: after reduction, shifting from state 0 to state 58
$220 = 23
(gdb) FAIL: gdb.base/exprs.exp: print with debugging
...
The test fails because it's not finding the string "Starting parse".
In this case, the .y files are processed used byacc. I suppose the testcase
matches the case that bison is used.
Fix this by grepping for something more generic: shift or Shift.
Jan Beulich [Fri, 8 Aug 2025 09:45:03 +0000 (11:45 +0200)]
bfd/ELF/Arm: make various arrays static / const
There's no reason to have the compiler materialize objects onto the
stack. And there's also no reason to allow comb[] and name_table[] to be
modifiable.
Jan Beulich [Fri, 8 Aug 2025 09:44:39 +0000 (11:44 +0200)]
bfd/ELF/RISC-V: make one local array static and several const
There's no reason for riscv_all_supported_ext[] to appear in libbfd.so's
dynamic symbol table. There's also no reason for various pieces of data
to live in .data, when .data.rel.ro or even .rodata can do.
Jan Beulich [Fri, 8 Aug 2025 09:44:12 +0000 (11:44 +0200)]
bfd/ELF: make three local arrays static
... and const. There's no reason to have the compiler copy anonymous
objects onto the stack. And there's also no reason to allow the arrays
to be modifiable.
Jan Beulich [Fri, 8 Aug 2025 09:43:02 +0000 (11:43 +0200)]
Arm: parse_neon_type() weaknesses
The custom parsing done there and in one of its callers allowed various
bogus constructs to be accepted. Insist on a non-zero leading digit when
parsing numbers, don't lose upper bits, and insist on proper separation
of operands.
Tom de Vries [Fri, 8 Aug 2025 08:51:18 +0000 (10:51 +0200)]
[gdb/testsuite] Add gdb.base/color-prompt.exp
After updating the documentation in commit cf03713dd1c ("[gdb/cli] Document
\001 and \002 usage for set prompt"), I started to wonder if I could reproduce
the CLI issue described in PR cli/28887 using the TUI.
That turned out not to be the case, but I noticed handling of the markers in
tui_puts and tui_puts_internal, and no test-case exercising this, so I
decided to add this.
After doing so in gdb.tui/color-prompt.exp, I realized I could use the same
code to test the CLI case.
Add test-case gdb.base/color-prompt.exp that shares code with
gdb.tui/color-prompt.exp in gdb.tui/color-prompt.exp.tcl.
For the CLI case, I was hoping to reproduce the behaviour described in the PR,
but it didn't trigger.
FTR, I manually reproduced the behaviour and used script to record it. I
observed the following sequence after the C-a:
- ^M (CR) : go to start of line
- ^[[K (EL) : erase line
- ^M (CR) : go to start of line
- ^[[31m(gdb) ^[[0m : output prompt
- some long command : output text
- ^M (CR) : go to start of line
- ^[[C, 15 times (CUF): cursor forward 15 times
giving me:
...
(gdb) some long command
^
...
Perhaps we'll trigger this on some other os, or once we start using a
different TERM value.
Tom de Vries [Fri, 8 Aug 2025 05:19:50 +0000 (07:19 +0200)]
[gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi
In ppc64_sysv_abi_return_value I came across this if clause:
...
/* Small character arrays are returned, right justified, in r3. */
if (valtype->code () == TYPE_CODE_ARRAY
&& !valtype->is_vector ()
&& valtype->length () <= 8
&& valtype->target_type ()->code () == TYPE_CODE_INT
&& valtype->target_type ()->length () == 1)
...
I decided to write a test-case to try and trigger this.
AFAIU, in C/C++, we're not allowed to return an array, so I wrote an Ada
test-case instead, with a function returning this type:
...
type T is new String (1 .. 4);
...
After doing so I realized that the clause above is not triggering because
valtype->target_type ()->code () == TYPE_CODE_CHAR. Fix this by allowing
both TYPE_CODE_INT and TYPE_CODE_CHAR.
Then I realized that the specific "small character array" handling comes from
the v1 abi. Add a check for this as well.
Tested on ppc64le-linux, with v2 abi.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Alan Modra [Wed, 6 Aug 2025 02:06:03 +0000 (11:36 +0930)]
Move struct plugin_data_struct to plugin.c
It isn't needed anywhere except plugin.c. The typedef can disappear.
Also make a forward declaraion for ld_plugin_input_file in plugin.h
so that this header can be used without first including plugin-api.h.
bfd/
* plugin.h (struct ld_plugin_input_file): Forward declare.
(struct plugin_data_struct): Move to..
* plugin.c: ..here.
(add_symbols): Size plugin_data without using type.
* archive.c: Don't include plugin-api.h.
* elflink.c: Likewise.
* format.c: Likewise.
binutils/
* ar.c: Don't include plugin-api.h or ansidecl.h. Only
include plugin.h when BFD_SUPPORTS_PLUGINS.
* nm.c: Don't include plugin-api.h. Only include plugin.h
when BFD_SUPPORTS_PLUGINS.
* objcopy.c: Likewise.
ld/
* ldfile.c: Don't include plugin-api.h.
* ldmain.c: Likewise.
gdb: change default initialization for register numbers on x86
As defined by the enums amd64_regnum and i386_regnum the register
numbering starts at 0.
Defaults for register numbers are currently set to 0 which seems to
be the wrong default. Set them to -1 instead. Configure the right
register number if we find out it's supported in i386_gdbarch_init.
Similarly we don't have to set the num_*regname* variables to 0 in
i386_gdbarch_init, as it's already assigned to 0 by default.
Approved-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Matthieu Longo [Mon, 4 Aug 2025 10:04:13 +0000 (11:04 +0100)]
libiberty: sync with gcc
Import the following commits from GCC as of r16-3056-gca2169c65bd169: 0d0837df697 libiberty: disable logging of list content for doubly-linked list tests
Xi Ruoyao [Wed, 6 Aug 2025 04:19:22 +0000 (12:19 +0800)]
LoongArch: Fix symbol size after relaxation
There's a logic error in loongarch_relax_perform_deletes: when there's
not any delete operation of which the start address is strictly smaller
than the symbol address, splay_tree_predecessor() will return nullptr
and the symbol size will be unchanged even if some bytes of it are
removed.
Make the logic more complete to fix this issue. Also factor out the
symbol size adjustment logic into a function to avoid code bloating.
Tested-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Xi Ruoyao <xry111@xry111.site>
An automated tester said that this patch caused a regression on
aarch64:
FAIL: gdb.arch/aarch64-atomic-inst.exp: Step through the ldxr/stxr sequence (timeout)
I looked into it a bit yesterday but couldn't see an obvious problem;
and it's somewhat of a pain to try to debug it at the moment.
Tom de Vries also noticed this and filed it in bugzilla. So, I'm
backing the patch out until I can port the failing test to the AdaCore
internal test suite in order to find out what went wrong.
"strip --strip-debug" no longer strips debug sections in fat IR objects
since fat IR objects are recognized as plugin object and copied as unknown
objects. Add a is_strip_input field to bfd to indicate called from strip.
Update bfd_check_format_matches not to treat archive member nor standalone
fat IR object as IR object so that strip can remove debug and IR sections
in fat IR object. For archive member, it is copied as an unknown object
if the plugin target is in use or it is a slim IR object. For standalone
fat IR object, it is copied as non-IR object.
bfd/
PR binutils/33246
* archive.c: Include "plugin-api.h" and "plugin.h" if plugin is
enabled.
(_bfd_compute_and_write_armap): Don't complain plugin is needed
when the plugin target is in use.
* bfd-in2.h: Regenerated.
* bfd.c (bfd): Add is_strip_input.
* format.c (bfd_set_lto_type): If there is .llvm.lto section,
set LTO type to lto_fat_ir_object.
(bfd_check_format_matches): Don't set LTO type when setting
format. When called from strip, don't treat archive member nor
standalone fat IR object as an IR object.
* plugin.c (bfd_plugin_get_symbols_in_object_only): Copy LTO
type derived from input sections.
nm/
PR binutils/33246
* nm.c (filter_symbols): Don't complain plugin is needed when
the plugin target is in use.
(display_rel_file): Likewise.
* objcopy.c (copy_archive): Set the BFD is_strip_input field of
archive member to 1 to indicate called from strip. Also copy
slim IR archive member as unknown object.
(copy_file): Set the BFD is_strip_input field of input bfd to
1 to indicate called from strip.
(strip_main): Keep .gnu.debuglto_* sections unless all GCC LTO
sections will be removed.
ld/
PR binutils/33246
* testsuite/ld-plugin/lto-binutils.exp (run_pr33246_test): New.
Run binutils/33246 tests with GCC and Clang.
* testsuite/ld-plugin/pr33246.c: New file.
Alan Modra [Tue, 5 Aug 2025 11:48:44 +0000 (21:18 +0930)]
Remove bfd_check_format_lto
Tidy changes to bfd_check_format_matches made by commit 9b854f169df9
which added a bfd_plugin_specified_p test and commit f752be8f916e
which added an lto_sections_removed arg. Both of these changes are
unnecessary if plugin_format is set to bfd_plugin_no before calling
bfd_check_format. bfd_plugin_no will prevent the plugin object_p
function from returning a match (and in the first case from a segfault
when loading plugins while a plugin is running). The plugin object_p
function already protected itself from recursive calls by setting
bfd_plugin_no before loading a plugin, but commit 9b854f169df9 opened
new bfds so they were unprotected.
It isn't strictly necessary to test for bfd_plugin_no in
bfd_check_format_matches but I kept the check to minimise functional
changes. Close inspection of the patch will notice I've added an
is_linker_input test too. That also isn't strictly necessary, I
think, but the match_count test was for the linker. See commit 999d6dff80fa.
PR 12291
PR 12430
PR 13298
PR 33198
bfd/
* format.c (bfd_check_format_lto): Revert to bfd_check_format.
(bfd_check_format_matches_lto): Revert to bfd_check_format_matches.
Correct comments. Manage both the lto_sections_removed and
bfd_plugin_specified_p cases by testing for bfd_plugin_no.
* plugin.c (bfd_plugin_get_symbols_in_object_only): Set
plugin_format to bfd_plugin_no before checking new bfds.
(try_load_plugin): Comment setting bfd_plugin_no.
(bfd_plugin_specified_p): Delete.
* plugin.h (bfd_plugin_specified_p): Delete.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Replace bfd_check_format_lto calls
with bfd_check_format using plugin_format set to bfd_plugin_no.
(check_format_object): New function.
(copy_file): Use it.
Tom Tromey [Tue, 5 Aug 2025 18:10:34 +0000 (12:10 -0600)]
Use '.rs' extension for Rust in gdb_simple_compile
While trying out gccrs, I noticed that gdb_simple_compile does not use
the ".rs" extension for Rust sources. This patch fixes the problem,
which lets gccrs get a little further in the test suite.
Tom Tromey [Mon, 4 Aug 2025 15:01:56 +0000 (09:01 -0600)]
Do not include cleanups.h from common-defs.h
Most code doesn't use cleanups any more, so remove the include of
cleanups.h from common-defs.h, and then only include that file where
it is truly needed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jannik Hartung [Tue, 5 Aug 2025 11:50:58 +0000 (13:50 +0200)]
[UI/TUI] Add support for italic and underline ANSI escape sequences
The ANSI escape sequence translation layer in TUI mode strips italic
or underlined text modes silently. You cannot output text formatted
like that using `TuiWindow.write` in Python at the moment.
Parse the ANSI escape sequences for italic and underlined text into
the `ui_file_style` structure and apply it to the TUI window when
applying styles, similar to preserving the bold/dim state already.
A script like this shows italic and underlined text correctly now.
```python
import gdb
def render(self) -> None:
self._tui_window.write("""
\x1b[4mThis is underlined.\x1b[24m And normal text.
\x1b[3mThis is italic.\x1b[23m And normal text.
""", True)
Tom de Vries [Mon, 4 Aug 2025 18:49:04 +0000 (20:49 +0200)]
[gdb/testsuite] Fix gdb.base/style.exp on freebsd
On x86_64-freebsd, with test-case gdb.base/style.exp I run into:
...
(gdb) print $_colorsupport \e[36;49;22;27m$1\e[m = "monochrome"
(gdb) FAIL: $exp: colorsupport_8color: color support is 8 color
...
Fix this by applying the same fix as for tuiterm: use TERM=ansiw instead of
TERM=ansi for bsd, getting us instead:
...
(gdb) print $_colorsupport \e[36;49;22;27m$1\e[m = "monochrome,ansi_8color"
(gdb) PASS: $exp: colorsupport_8color: color support is 8 color
...
Tom Tromey [Wed, 7 Jun 2023 15:32:46 +0000 (09:32 -0600)]
Disabling hardware single step in gdbserver
This patch gives gdbserver the ability to omit the 's' reply to
'vCont?'. This tells gdb that hardware single-step is definitely not
supported, causing it to fall back to using software single-step.
This is useful for testing the earlier change to
maybe_software_singlestep.
Tom Tromey [Wed, 7 Jun 2023 14:56:03 +0000 (08:56 -0600)]
Call target_can_do_single_step from maybe_software_singlestep
When the PikeOS osabi sniffer was added, Pedro suggested that a target
could omit stepping from its vCont? reply packet to tell gdb that
software single-step must be used:
This patch implements this idea by moving the call to
target_can_do_single_step into maybe_software_singlestep.
I've also removed some FIXME comments from gdbarch_components.py, and
slightly updated the documentation for gdbarch_software_single_step.
I think these comments are somewhat obsolete now that
target_can_do_single_step exists -- the current approach isn't exactly
what the comments intended, but on the other hand, it exists and
works.
Following review comments from Andrew, this version changes
record-full to use maybe_software_singlestep, and then combines
maybe_software_singlestep with insert_single_step_breakpoint.
Alan Modra [Sat, 2 Aug 2025 05:52:15 +0000 (15:22 +0930)]
windres PR 33244 testcase
Make the windres testing both parse .rc files to binary and back
again. It's not possible to compare against the original .rc file
unfortunately, but at least this checks for the segfault fixed by
commit 891d1654d731.
PR 33244
* testsuite/binutils-all/windres/psql.rc: New file.
* testsuite/binutils-all/windres/windres.exp: Do a -J res
-O rc conversion too. Correct verbose message.
H.J. Lu [Thu, 31 Jul 2025 13:30:59 +0000 (06:30 -0700)]
gprof: Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh
Both tst-gmon-gprof.sh and tst-gmon-gprof-l.sh generate gmon.out and
process it. Run tst-gmon-gprof-l.sh after tst-gmon-gprof.sh to avoid
the race condition.
* testsuite/Makefile.am (tst-gmon-gprof-l.out): Depend on
tst-gmon-gprof.out.
* testsuite/Makefile.in: Regenerated.
Andrew Burgess [Tue, 8 Jul 2025 13:28:03 +0000 (14:28 +0100)]
gdbserver: switch to using getopt_long for argument processing
Update gdbserver to use getopt_long for argument processing. This
turned out to be easier than I expected.
Interesting parts of this patch are:
I pass '+' as the OPTSTRING to getopt_long, this prevents getopt_long
from reordering the contents of ARGV. This is needed so that things
like this will work:
gdbserver :54321 program --arg1 --arg2
Without the '+', getopt_long will reorder ARGV, moving '--arg1' and
'--arg2' forward and handling them as arguments to gdbserver.
Because of this (not reordering) and to maintain backward
compatibility, we retain a special case to deal with '--attach' which
can appear after the PORT, like this:
gdbserver :54321 --attach PID
I did consider adding a warning to this special case, informing the
user that placing --attach after the PORT was deprecated, but in the
end I didn't want to really change the behaviour as part of this
commit, so I've left that as an optional change for the future.
The getopt_long function supports two value passing forms, there is
'--option=value', and also '--option value'. Traditionally, gdbserver
only supports the first of these. To maintain this behaviour, after
the call to getopt_long, I spot if '--option value' was used, and if
so, modify the state so that it seems that no value was passed, and
that 'value' is the next ARGV entry to be parsed. We could, possibly,
remove this code in the future, but that would be a functional change,
which is not something I want in this commit.
Handling of "-" for stdio connection has now moved out of the argument
processing loop as '-' isn't considered a valid option by getopt_long,
this is an improvement as all PORT handling is now in one place.
I've tried as much as possible to leave user visible functionality
unchanged after this commit, and as far as I can tell from testing,
nothing has changed.
Andrew Burgess [Sat, 12 Jul 2025 12:29:19 +0000 (13:29 +0100)]
gdbserver: exit with code 1 after missing packet name
When using the command:
$ gdbserver --disable-packet
gdbserver lists all the packets that can be disabled, and then exits.
I think that this output is a helpful error message that is printed
when the user has forgotten to entry a packet name. We get similar
output if we run the command:
$ gdbserver --disable-packet=foo
where gdbserver tells us that 'foo' is invalid, and then lists the
packets that we can use.
The difference is that, in the first case, gdbserver exits with a code
of 0, and in the second, gdbserver exits with a code of 1.
I think both these cases should exit with a code of 1.
With the exception of '--help' and '--version', where we are asking
gdbserver to print some message then exit (which are, and should exit
with a code of 0), in all other cases where we do an early exit, I
think this is an indication that the user has done something
wrong (entered and invalid argument, or missed an argument value), and
gdbserver should exit with a non-zero exit code to indicate this.
This commit updates the exit code in the above case from 0 to 1.
Jan Beulich [Fri, 1 Aug 2025 07:18:31 +0000 (09:18 +0200)]
opcodes/x86: make i386_mnem[] static
With the tables no longer being part of libopcodes (but rather being
compiled directly into gas), this table doesn't need exposing anymore.
The declaration cannot be avoided, though, as the first use of the
array sits ahead of its definition (in i386-tbl.h).
Jan Beulich [Fri, 1 Aug 2025 07:18:15 +0000 (09:18 +0200)]
opcodes/riscv: make riscv_options[] const
There's no reason to allow the array to be modifiable. In fact the
compiler is able to infer this, placing the array in .data.rel.ro, but
let's make it explicit.
Merge them into a single array of struct type. There's further no reason
to have the compiler materialize such objects on the stack. And there's
also no reason to allow the array(s) to be modifiable. Finally, given
how short the strings are, there's little point using more space to
store pointers to them (on 64-bit hosts; the situation is a little
better on 32-bit ones).
While there also correct indentation in adjacent code, and avoid open-
coding ARRAY_SIZE().
Simon Marchi [Wed, 9 Jul 2025 15:35:13 +0000 (11:35 -0400)]
gdb/dwarf: sort dwarf2_per_bfd::all_units by (section, offset)
This patch started as a fix for PR 29518 ("GDB doesn't handle
DW_FORM_ref_addr DIE references correctly with .debug_types sections")
[1], but the scope has expanded a bit to fix the problem more generally,
after I spotted a few issues related to the order of all_units. The
first version of this patch is here [2].
PR 29518 shows that dwarf2_find_containing_comp_unit can erroneously
find a type unit. The obvious problem is that the
dwarf2_find_containing_comp_unit function searches the whole all_units
vector (containing both comp and type units), when really it should just
search the compilation units. A simple solution would be to make it
search the all_comp_units view (which is removed in a patch earlier in
this series).
I then realized that in DWARF 5, since type units are in .debug_info
(versus .debug_types in DWARF 4), type units can be interleaved with
comp type in the all_units vector. That would make the all_comp_units
and all_type_units views erroneous, and dwarf2_find_containing_comp_unit
could still return something wrong. In v1, I added a sort in
finalize_all_units to make sure all_units is in the order that
dwarf2_find_containing_comp_unit expects:
- comp units from the main file
- type units from the main file
- comp units from the dwz file
- type units from the dwz file (not actually supported, see PR 30838)
Another problem I spotted is that the .gdb_index reader creates units in
this order:
- comp units from .gdb_index from main file
- comp units from .gdb_index from dwz file
- type units from .gdb_index from main file
This isn't the same order as above, so it would need the same sort step.
Finally, I'm not exactly sure if and when it happens, but it looks like
lookup_signatured_type can be called at a later time (after the initial
scan and creation of dwarf2_per_cu object creation), when expanding a
symtab. And that could lead to the creation of a new type unit (see
function add_type_unit), which would place the new type unit at the end
of the all_units vector, possibly screwing up the previous order.
To handle all this in a nice and generic way, Tom Tromey proposed to
change the all_units order, so that units are sorted by section, then
section offset. This is what this patch implements. The sorting is
done in finalize_all_units.
This works well, because when looking up a unit by section offset, the
caller knows which section the unit is in. Passing down a (section,
section offset) tuple makes it clear and unambiguous what unit the
caller is referring to. It should help eliminate some bugs where the
callee used the section offset in the wrong section. Passing down the
section along with the section offset replaces the "is_dwz" flag passed
to dwarf2_find_containing_comp_unit and a bunch of other functions in a
more general way.
dwarf2_find_containing_comp_unit can now legitimately find and return
type units even though it should be needed (type units are typically
referred to by signature). But I don't think there is harm for this
function to be more generic than needed. I therefore I renamed it to
dwarf2_find_containing_unit.
The sort criterion for "section" can be anything, as long as we use the
same for sorting and searching. In this patch, I use the pointer to
dwarf2_section_info, because it's easy. The downside is that the actual
order depends on what the memory allocator decided to return, so could
change from run to run, or machine to machine. Later, I might change it
so that sections are ordered based on their properties, making the order
stable across the board. This logic is encapsulated in the
all_units_less_than function, so it's easy to change.
The .debug_names reader can no longer rely on the order of the all_units
vector for its checks, since all_units won't be the same order as found
in the .debug_names lists. In fact, even before, it wasn't: this check
assumed that .debug_info had all CUs before TUs, and that the index
listed them in the exact same order. When I build a file with gcc and
"-gdwarf-5 -fdebug-types-section", type units appear first in
.debug_info. This caused GDB to reject a .debug_names index that is had
produced:
⚠️ warning: Section .debug_names has incorrect entry in CU table, ignoring .debug_names.
To make it work, add a new dwarf2_find_unit function that allows looking
up a unit by start address (unlike dwarf2_find_containing_unit, which
can find by any containing address), and make the .debug_names reader
use it. It might make the load time of .debug_names a bit longer (the
build and check step is now going to be O(n*log(n)) instead of O(n)
where n is the number of units, or something like that), but I think
it's important to be correct here.
This patch adds a test
(gdb.dwarf2/dw-form-ref-addr-with-type-units.exp), which tries to
replicate the problem as shown by PR 29518.
gdb.base/varval.exp needs a small change, because an error message
changes (for the better, I think)
gdb.dwarf2/debug-names-non-ascending-cu.exp now fails, because GDB no
longer rejects a .debug_names index which lists CUs in a different order
than .debug_info. Given the change I did to the .debug_names reader,
explained above, I don't think this is a problem anymore (GDB can accept
an index like that). I also don't think that DWARF 5 mandates that CUs
are in ascending order. Delete this test.
Simon Marchi [Wed, 9 Jul 2025 15:35:12 +0000 (11:35 -0400)]
gdb/dwarf: sort units when writing index
The order of all_units can't be relied on when writing the CU and TU
lists to .gdb_index or .debug_names.
Both the .gdb_index and .debug_names writers expect that all_units
contains comp units followed by type units. As of this commit, when
reading a DWARF 5 .debug_info, the all_units vector is ordered based on
the order the units appear in .debug_info, where type units can be
interleaved with comp units.
It probably worked fine with DWARF 4, where type units were in a section
of their own (.debug_types). They were read after comp units, and
therefore after them in the all_units vector.
Change the writers to use a common function that splits the units in two
lists (comp units and type units). Sort both lists by section offset.
This is more than required, but it should help produce a stable and
predictable output.
Change-Id: I5a22e2e354145e3d6b5b2822dc2a3af2f9d6bb76 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 9 Jul 2025 15:35:11 +0000 (11:35 -0400)]
gdb/dwarf: make .gdb_index reader use its own list of units
The .gdb_index reader currently uses per_bfd::all_units when translating
a numerical index (as found in an index entry) to a dwarf2_per_cu. The
order of per_bfd::all_units is going to change in a subsequent patch, so
the indices as found in the index won't map to the right unit in
all_units. Change the .gdb_index reader to maintain its own vector,
with the units in the same order as found in the .gdb_index header.
This is similar to what the .debug_names reader does. But unlike
.debug_names, .gdb_index treats the CUs and TUs as a single list, as far
as the numerical indices are concerned, so we only need a single list
here (versus two for .debug_names).
Change-Id: I235e9b99bf02fc160dfcdaa610c9aca471f298a7 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 9 Jul 2025 15:35:10 +0000 (11:35 -0400)]
gdb/dwarf: move index unit vectors to .debug_names reader and use them
The all_comp_units_index_cus and all_comp_units_index_tus vectors
contain the CU and TU lists as found in the .debug_names list. It seems
like they are meant to be used by the .debug_names reader when handling
a DW_IDX_compile_unit or DW_IDX_type_unit attribute. The value of the
attribute would translate directly into an index into one of these
vectors.
However, it looks like these vectors aren't actually used in practice.
They are used in the dwarf2_per_bfd::get_index_{c,t}u methods, which in
turn aren't used anywhere.
The handlers of DW_IDX_compile_unit and DW_IDX_type_unit use the
dwarf2_per_bfd::get_unit method, with the assumption that
dwarf2_per_bfd::all_units has comp units before type units. This is not
the case: the .debug_names reader creates the units in
dwarf2_per_bfd::all_units using the create_all_units function, which
creates the units in the order found in .debug_info, where type units
can be interleaved with comp units.
Since those vectors are specific to the .debug_names reader, move them
to the mapped_debug_names_reader struct. Then, update the handlers of
DW_IDX_compile_unit and DW_IDX_type_unit to actually use them.
Change-Id: Ie7db81f4442f634ac6d02280a60c6c671bcd22a5 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 9 Jul 2025 15:35:09 +0000 (11:35 -0400)]
gdb/dwarf: remove all_{comp,type}_units views
In DWARF 5, type units appear in the .debug_info section, interleaved
with comp units, and the order in all_units reflects that. The
all_comp_units and all_type_units views are wrong in that case
(all_comp_units contains some type units, and vice-versa).
It would be possible to manually sort all_units to ensure that type
units follow comp units, but this series takes the approach of sorting
the units by section and section offset.
Remove those views, and replace their uses with num_comp_units and
num_type_units. It appears that the views were only used to know the
number of each kind.
The finalize_all_units function is now empty, but I am keeping it
because a subsequent patch adds a call to std::sort in there to sort the
all_units vector.
Change-Id: I42a65b6f1b6192957b55cea0e2eaff097e13a33b Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Wed, 9 Jul 2025 15:35:08 +0000 (11:35 -0400)]
gdb/dwarf: track compilation and type unit count
A subsequent commit will remove the all_comp_units and all_type_units
array views, since it's not possible to assume that that all_units
vector is segmented between comp and type units. Some callers still
need to know the number of each kind, so track that separately.
Change-Id: I712fbdfbf10b333c431b688b881cc0987e74f688 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Thu, 31 Jul 2025 21:40:40 +0000 (07:10 +0930)]
ia64 assembler warning breaks ld tests
The "Warning: Explicit stops are ignored in auto mode" results in
failures of a number of run_ld_link_tests because the compiler is run
using -S and then the resulting .s file assembled without suppplying
-x to gas. Fix that problem by adding -x to ASFLAGS for ia64, and
tweak the binutils link-order test since the source is used in a ld
test too.
ld/
* testsuite/config/default.exp: Set ASFLAGS to "-x" for ia64.
Remove unnecessary "global".
binutils/
* testsuite/binutils-all/link-order.s: Provide explicit stop.
* testsuite/binutils-all/objcopy.exp: Pass "-x" when building
link-order test for ia64.
projects / thirdparty / binutils-gdb.git / log
