Simon Marchi [Mon, 11 May 2026 15:40:32 +0000 (11:40 -0400)]
gdb/dwarf: add more context to complaints in mapped_debug_names_reader::scan_one_entry
I realize that complaints are not often enabled and shown, but if we
emit them, I think they should include enough context to help a user who
wishes to dig in the problem to pinpoint where the problem happened
exactly. For this reason, change the complaints in
mapped_debug_names_reader::scan_one_entry to include precisions
regarding which index entry is problematic exactly.
I am not attached to the particular format. I thought that because this
is extra contextual information, I would put it in the square brackets
at the end (which only shows the module name currently). However, it
would be nice to converge towards a format that we could replicate
elsewhere in the DWARF reader, so feel free to chime in.
I factored out the formatting to a separate function, because I will be
adding more of these in a subsequent patch, and it's easier to have the
formatting centralized.
I have not touched the "Unsupported .debug_names form" warning. If that
comes up, we probably don't care about the specific index entry, we just
need to implement support for that form.
Change-Id: Id68a0ae406a3ca620408576b81f893f05c7e3df2 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 May 2026 15:40:31 +0000 (11:40 -0400)]
gdb/dwarf: add debug output in read-debug-names.c
Add a bunch of debug prints in read-debug-names.c to dump what we are
reading. Some of if was helpful to me when debugging my changes to the
.debug_names reader and writer.
The debug prints are activated by "set debug dwarf-read" (I didn't feel
like we needed a separate knob for that). There are two levels of
verbosity. At level 1, we print everything that happens once, like the
header, counts, offsets of important parts of the index, etc. At
levels > 1, we print information about each abbrev, CU/TU and index
entry.
The output is made such that it is easy look at the output of readelf of
llvm-dwarfdump on the side and confirm that GDB is reading the index
right.
[dwarf-read] build_and_check_cu_list_from_debug_names: building CU list from .debug_names (56 CUs)
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 0: offset 0x0
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 1: offset 0x1bac
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 2: offset 0x4262
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 3: offset 0x4ff0
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 4: offset 0x59e9
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 5: offset 0x67af
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 6: offset 0x8e1a
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 7: offset 0xa5cc
[dwarf-read] build_and_check_cu_list_from_debug_names: CU 8: offset 0xcd39
Some entries:
[dwarf-read] scan_all_names: start: scanning 3418 names from .debug_names
[dwarf-read] scan_entries: scanning entries for name 1: "(anonymous namespace)" (entry pool offset 0x0)
[dwarf-read] scan_one_entry: entry pool offset 0x0: abbrev 1, tag DW_TAG_namespace
[dwarf-read] scan_one_entry: DW_IDX_compile_unit (DW_FORM_udata): 55
[dwarf-read] scan_one_entry: DW_IDX_die_offset (DW_FORM_ref_addr): 0x7d06b
[dwarf-read] scan_one_entry: DW_IDX_GNU_language (DW_FORM_udata): 33
[dwarf-read] scan_one_entry: DW_IDX_parent (DW_FORM_data4): 38201
[dwarf-read] scan_one_entry: -> die_offset 0x7d06b, per_cu offset 0x5af0e
[dwarf-read] scan_one_entry: entry pool offset 0xb: end of entries (abbrev 0)
[dwarf-read] scan_entries: scanning entries for name 2: "AUTO_SEEK_STREAM_STATE_PACKET_BEGAN" (entry pool offset 0xc)
[dwarf-read] scan_one_entry: entry pool offset 0xc: abbrev 2, tag DW_TAG_enumerator
[dwarf-read] scan_one_entry: DW_IDX_compile_unit (DW_FORM_udata): 17
[dwarf-read] scan_one_entry: DW_IDX_die_offset (DW_FORM_ref_addr): 0x1beea
[dwarf-read] scan_one_entry: DW_IDX_GNU_language (DW_FORM_udata): 29
[dwarf-read] scan_one_entry: DW_IDX_GNU_internal (DW_FORM_flag_present): 1
[dwarf-read] scan_one_entry: -> die_offset 0x1beea, per_cu offset 0x1a28e
[dwarf-read] scan_one_entry: entry pool offset 0x13: end of entries (abbrev 0)
Change-Id: I4a40bfb73fa7feccb5038814a7d1a1bcd4f6231b Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 May 2026 15:40:30 +0000 (11:40 -0400)]
gdb/dwarf: generate foreign type units in .debug_names
The DWARF 5 .debug_names index makes the distinction between local type
units and foreign type units. Local type units are those present
directly in the main file. Foreign type units are those present in .dwo
files. GDB only knows how to produce local type units today, which
leads to invalid indexes whenever there are type units in .dwo files.
To observe this, run test gdb.dwarf2/fission-with-type-unit.exp with
board cc-with-debug-names. The test passes, but we see this in the log:
(gdb) file
/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/fission-with-type-unit^M
Reading symbols from
/home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/fission-with-type-unit...^M
warning: Section .debug_names has incorrect entry in TU table,
ignoring .debug_names.^M
These are the units involved in this test. The first and last CUs are
dummy CUs added by the DWARF assembler, they are not important.
- CU at offset 0x0 of .debug_info in fission-with-type-unit -- dummy
- CU at offset 0xc of .debug_info in fission-with-type-unit
- CU at offset 0x25 of .debug_info in fission-with-type-unit -- dummy
- TU at offset 0x0 of .debug_info.dwo in fission-with-type-unit-dw.dwo
The TU table claims that there is a TU at offset 0 in the main file
(fission-with-type-unit). This is wrong: the TU is in
fission-with-type-unit-dw.dwo. It should be listed in the Foreign TU
table instead.
This patch therefore teaches GDB to use the foreign TU table for TUs in
.dwo files.
A note about foreign type units and skeletons: in the early history of
split DWARF and type units, gcc 4.x used to create skeletons for type
units in .dwo files, but subsequent versions don't. DWARF 5 doesn't
have support for type unit skeletons at all. So skeletons for type
units are mostly a historical curiosity at this point, the norm is to
not have them. But if for some reason a type unit in a .dwo file had a
matching skeleton in the main file, then it would be ok for that TU to
be listed in the "TU table". The offset would be that of the skeleton.
While the list of CUs and local TUs contain the offset within the
.debug_info section where to find the unit, the foreign TU list only
contains the 8-byte signature of the types. With just that, a reader
wouldn't be able to easily locate a .dwo that contain the type with a
given signature.
To help with this, index entries for foreign type units may also include
a reference to a compilation unit that can be followed in order to find
a .dwo file containing the type. This patch implements it.
Implementation details
----------------------
The first change is the addition of the dwo_unit::per_cu field, which
allows going from the dwo_unit to the dwarf2_per_cu structure (which
describes the skeleton) that was used to lookup this dwo_unit. This
fields starts at nullptr, and it gets set in lookup_dwo_cutu whenever we
look up the dwo_unit for a given dwarf2_per_cu. This will come handy
later. I made this field an std::atomic, because I think it would be
possible to craft a weird test case that would make two indexer threads
try to set the field on the same dwo_unit. During normal operation, we
expect the field for each dwo_unit representing a CU to be written
exactly once.
In index-write.c, change the get_unit_lists function in
dwarf2/index-write.c to segregate local and foreign type units. Then,
update write_debug_names to emit the list of foreign TUs in the
.debug_names header. This consists of a list of type signatures.
In debug_names::build, for foreign type units, emit a
DW_IDX_compile_unit field. This is the reference to the CU that can be
used to locate the .dwo file containing that type unit. To obtain the
value for this field, look up a CU in the same dwo_file that has its
dwo_unit::per_cu field set (typically there will be exactly one CU, and
the field will be set).
With this patch, the index for the test case above looks like:
We can see that the TU is correctly placed in the foreign TU list, and
that the index entry (the last line) points to the TU at index 0, but
also to the CU at index 1, which is indeed the CU that the reader can
follow to find the type unit.
With this patch, GDB still rejects the index:
(gdb) file /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/fission-with-type-unit
Reading symbols from /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/fission-with-type-unit...
warning: Section .debug_names in /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/fission-with-type-unit has unsupported 1 foreign TUs, ignoring .debug_names.
But at least, we don't produce a bogus index anymore, that's already an
improvement. A following patch in this series implements the reading
side
Change-Id: I311fd7b4ca57d9ff6d64ae08df805c6635961eed Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 May 2026 15:40:29 +0000 (11:40 -0400)]
gdb/dwarf: add dwo_file::find_tus
Add this little helper to make finding a TU a bit simpler. I always
find the STL way of doing things cryptic, so I think that hiding it in
small helper methods makes the code clearer.
A subsequent patch will add more uses of it
Change-Id: Ibfb20d0e44c65d2ff729f3e0980ec4435f223aef Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 May 2026 15:40:28 +0000 (11:40 -0400)]
gdb/dwarf: move dwarf2_cu::section to cu.c
Following the previous patch that moves the dwo_unit structure from
dwarf2/read.c to dwarf2/dwo.h, dwarf2_cu::section has no reason to be
implemented in dwarf2/read.c anymore. Move it to dwarf2/cu.c.
Change-Id: I67e2bb42d878ac18e4bf3460d75f1394477a46ce Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Mon, 11 May 2026 15:40:27 +0000 (11:40 -0400)]
gdb/dwarf: move dwo_unit and dwo_file to dwo.h
Move these types and some related things to a new dwo.h header file. My
goal is to allow index-write.c to see these types, in a later patch. I
initially moved them to read.h, but Tom suggested in review that read.h
was getting a bit too large.
Change-Id: Ia32e0643f95561d3a1bfb67d501c8e20f5682f0e Approved-By: Tom Tromey <tom@tromey.com>
Pedro Alves [Mon, 23 Mar 2026 21:54:12 +0000 (21:54 +0000)]
gcore: handle known-all-zeroes hole mappings
This commit improves core generation on Linux. The issue this
addresses became apparent when dumping core of HIP programs on AMD
GPUs, but it's strictly a CPU-side issue.
The AMD GPU runtime used by HIP (and other languages) programs creates
these big mappings in every program, the size of GPU VRAM. E.g., on
gfx942 with 256GB VRAM, we end up with 256GB of such mappings:
GDB's gcore, not knowing the mappings contain only zeroes, reads all
their contents from inferior memory, all 256GB of it. On gfx942, that
makes the gcore command take around 1 minute when dumping a small HIP
program.
GDB's gcore currently generates load segments of these mappings like
this:
The fact that GDB makes CONTENTS/LOAD segments makes it so that the
resulting core files are much larger than what the Linux kernel
produces (note "File off" column), even though it's mostly apparent
size as gdb knows how to produce sparse cores:
$ ls -als --hu core/*
440M -rw------- 1 pedalves pedalves 474M Mar 24 08:14 core/kernel.core
51M -rw-rw-r-- 1 pedalves pedalves 257G Mar 24 08:16 core/gdb-before.core
^^^^ real ^^^^ apparent
This commit teaches linux-tdep.c to identify anonymous mappings that
have no backing data from /proc/pid/smaps (which we already parse), so
that the gcore code can skip reading inferior memory for them, and
their load segments can be emitted with no CONTENTS/LOAD.
The skip-reading-inferior-memory part speeds up core dumping of small
HIP inferiors on gfx942 GPUs by a large factor. E.g.:
With:
$ time rocgdb --batch -q small-test-program \
-ex "with breakpoint pending on -- b gpu_code" \
-ex "r" \
-ex "gcore" \
-ex "k"
On gfx942, before the patch:
real 1m6.518s
user 0m5.984s
sys 1m0.218s
On gfx942, after the patch:
real 0m4.456s
user 0m2.219s
sys 0m1.829s
And the fact that we no longer emit segments with CONTENTS/LOAD makes
the resulting gdb-generated cores's apparent size be much smaller,
closer to kernel-generated core file's:
$ ls -als --hu core/*
440M -rw------- 1 pedalves pedalves 474M Mar 24 08:14 core/kernel.core
51M -rw-rw-r-- 1 pedalves pedalves 257G Mar 24 08:16 core/gdb-before.core
52M -rw-rw-r-- 1 pedalves pedalves 642M Mar 24 09:12 core/gdb-after.core
This commit also adds a new testcase that exercises both the scenario
in question (without relying on the HIP runtime), and the converse of
making sure that we don't skip dumping anonymous private PROT_NONE
mappings with backing data, by mistake.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I2cf21409af36266094bcff5614770605fab4030e
commit-id: d3d471d8
Tom de Vries [Mon, 11 May 2026 09:50:13 +0000 (11:50 +0200)]
[gdb/testsuite] Fix gdb.dap/corefile.exp with Tcl 9.0
With test-case gdb.dap/corefile.exp and Tcl 9.0 I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.dap/corefile.exp.
ERROR: tcl error code TCL LOOKUP VARNAME reg_name
ERROR: can't read "reg_name": no such variable
while executing
"s \$$reg_name"
(in namespace eval "::ton::2json" script line 1)
invoked from within
"namespace eval ton::2json $obj"
...
Fix this by making clear that reg_name is a variable in the global namespace.
The comment of store_integer seems slightly outdated and does not refer to
the variants that take an array view. Update the comment and add comments
to the various instantiations.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The Debian maintainer of babeltrace (Michael, in CC) is working
towards removing the version 1 package from the archive in favour of
version 2. This makes sense as version 1 is unsupported and projects
should move to version 2.
While digging through the archives I found PR buid/27142 (from
Matthias, also in Cc) which was filed 5 years ago requesting GDB to
support babeltrace v2. At the time Simon started a thread on gdb@
suggesting that we should actually remove the support for CTF (Common
Trace Format) altogether, since it's a niche feature (CTF) within a
niche feature (tracepoints) and apparently GDB itself records CTF data
in an unconventional way that might break other tools. You can see
the thread here:
Long story short, the consensus seems to be that CTF support is ripe
to be removed, so that's what this patch does. I think I covered all
places that referred to either CTF or babeltrace; I recompiled GDB
here and things are still working as expected. I ran the tests I
touched and there are some failures, but they're unrelated to CTF and
I could reproduce them in a pristine tree as well.
I've been a bit distant from the community so I don't know whether we
have a specific procedure to remove features from GDB. I remember
that when we removed support for an architecture, we used to deprecate
it in release N and then proceed with the removal on release N+1. Not
sure if this is applicable here, but let me know.
Either way, I intend to disable support for babeltrace on Debian's GDB
soon.
WDYT?
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27142 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
so update `is_elf_format' accordingly, complementing commit d85e70a35bff
("Add support for the haiku operating system.") and fixing regressions:
aarch64-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
aarch64-haiku -FAIL: GNU attributes v2: no support for directive .gnu_subsection
arm-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
m68k-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
mipsel-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
powerpc-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
sparc64-haiku -FAIL: GNU attributes v1/v2: no support for directive .gnu_attribute
sparc64-haiku -FAIL: sparc relax CALL (a.out)
while widely broadening coverage, e.g. with `i486-haiku' we now get:
=== binutils Summary ===
# of expected passes 230
# of untested testcases 18
# of unsupported tests 21
=== gas Summary ===
# of expected passes 1066
# of unsupported tests 16
=== ld Summary ===
# of expected passes 595
# of expected failures 2
# of untested testcases 26
# of unsupported tests 215
vs:
=== binutils Summary ===
# of expected passes 77
# of untested testcases 13
# of unsupported tests 11
=== gas Summary ===
# of expected passes 806
# of unsupported tests 4
=== ld Summary ===
# of expected passes 188
# of expected failures 2
# of untested testcases 16
# of unsupported tests 62
The following regressions yet need to be addressed:
i386/Haiku/GAS/testsuite: Suppress SVR4 comment character test
Exclude the SVR4 comment character test on Haiku targets, as `/' is not
a comment character there (cf. gas/config/te-haiku.h), so as to prevent
a regression caused by enabling ELF tests with Haiku targets:
Aarch64/Haiku/binutils/testsuite: Suppress PEI test
There is no PEI BFD target included by default with the Haiku target
configuration, so exclude the EFI test, preventing a regression caused
by enabling ELF tests with Haiku targets:
aarch64-haiku +FAIL: Check if efi app format is recognized
Simon Marchi [Mon, 10 Nov 2025 21:19:40 +0000 (16:19 -0500)]
gdb: refuse to produce .gdb_index when skeletonless type units are present
Running test gdb.dwarf2/fission-with-type-unit.exp with the
cc-with-gdb-index target board fails with:
(gdb) maint expand-symtabs
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:3064: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)
This is a consequence of .gdb_index not supporting skeletonless type
units in .dwo files. That is, type units in .dwo files that don't have
a corresponding skeleton (or stub) in the main file.
For context: in DWARF 4, gcc 4.x used to create skeletons for type units
in .dwo files, but subsequent versions don't. DWARF 5 doesn't have
support for type unit skeletons at all. So skeletons for type units are
mostly a historical curiosity at this point, the norm is to not have
them.
Here's what leads up to the crash. First, this is what is in the main
file's .debug_info section (the first and last CUs are dummy CUs added
by the testsuite):
After loading the above in GDB, here is what is in GDB's mind (contents
of dwarf2_per_bfd::all_units):
- CU at offset 0x0 of .debug_info in fission-with-type-unit -- dummy
- CU at offset 0xc of .debug_info in fission-with-type-unit
- CU at offset 0x25 of .debug_info in fission-with-type-unit -- dummy
- TU at offset 0x0 of .debug_info.dwo in fission-with-type-unit-dw.dwo
This is correct. Then, this is the generated .gdb_index:
Shortcut table:
Language of main: unknown: 0
Name of main: <unknown>
The TU table says that there exists a TU at offset 0. Unfortunately,
there is no way for a reader of that index to know that this TU is
really in a .dwo file, not in the main file. So when GDB loads this
index back (creating dwarf2_per_bfd::all_units from .gdb_index this
time, rather than walking the debug info), this is what is in its mind:
- CU at offset 0x0 of .debug_info in fission-with-type-unit -- dummy
- TU at offset 0x0 of .debug_info in fission-with-type-unit
- CU at offset 0xc of .debug_info in fission-with-type-unit
- CU at offset 0x25 of .debug_info in fission-with-type-unit -- dummy
GDB now incorrectly believes there's a TU at offset 0 of .debug_info in
the main file, which is wrong. When trying to expand that TU with
"maint expand-symtabs", we're not really reading the TU, so we hit the
assert checking that the signature in the TU header matches what was
given by the index.
The .debug_names format has a way to list the TUs found in the .dwo
files, called the "foreign TU list" (see section 6.1.1.2 "Structure of
the Name Index" of DWARF 5). That list only includes the signature of
the type, and there is some capability to figure out which .dwo file
contains that type unit. The .gdb_index format does not have something
like that. We could try to retrofit such a feature in the .gdb_index
format, but I think we prefer to put our efforts on the standard
.debug_names format.
To avoid producing a misleading index like shown above, I propose to
make GDB refuse to produce an index if there exists a skeletonless type
unit. This patch implements that by looking at section of all
signatured_types. If the containing section ends with .dwo, then this
is a skeletonless type unit.
As a reminder: if a unit has a skeleton, the dwarf2_per_cu section will
point at the skeleton section, in the main file. If the unit does not
have a skeleton, the dwarf2_per_cu section will point at the section in
the .dwo file. All .dwo section names end with ".dwo".
Add a "endswith" utils function to help with that.
With this patch, running the gdb.dwarf/fission-with-type-unit.exp leads
to a compilation failure:
gdb compile failed, Error while writing index for `/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit': Found skeletonless type units, unable to produce .gdb_index. Consider using .debug_names instead.
... which makes the test "untested".
Add a new test, gdb.dwarf2/gdb-index-skeletonless-tu.exp, to verify the new error path.
Change-Id: I1e2e0204c9c2b48763aa99ce63521ae4a5262b22 Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
GDB: testsuite: threads: Don't return value from top-level (manual)
This patch manually changes "return -1" statements that weren't caught
by the sed command.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as for loops,
with_test_prefix, foreach_with_prefix, gdb_test_multiple.
I also fixed a couple cases of "return 0" from top-level that also
weren't caught by sed, and even a couple cases of "return 1" from
top-level.
GDB: testsuite: threads: Don't return 0 from top-level (sed)
This patch is a bit different than the others. I noticed that
gdb.threads has many cases of "return 0" from the top level, so this
patch is purely the result of running:
$ sed -i 's/^ return 0/ return/' *.exp*
inside gdb/testsuite/gdb.threads.
There were a number of false positives so not all sed changes were
incorporated.
GDB: testsuite: reverse: Don't return value from top-level (manual)
This patch manually changes "return -1" statements that weren't caught
by the sed command. It also changes a few "return 0" statements.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as with_test_prefix,
foreach_with_prefix, with_timeout_factor, gdb_test_multiple.
GDB: testsuite: MI: Don't return value from top-level (manual)
This patch manually changes "return -1" statements that weren't caught
by the sed command. It also changes a couple of "return 0" statements.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as with_test_prefix,
foreach_with_prefix, gdb_expect.
GDB: testsuite: Python: Don't return value from top-level (manual)
This patch manually changes "return -1" and "return 0" statements that
weren't caught by the sed command.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as save_vars,
with_test_prefix, foreach, gdb_test_multiple.
In a couple of cases the whole if block was in a single line:
if { condition } { return -1 }
In those cases the formatting was changed to the multi-line style we
tend to use.
GDB: testsuite: DWARF: Don't return -1 from top-level (manual)
This patch manually changes "return -1" statements that weren't caught
by the sed command.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as save_vars,
with_test_prefix, foreach, gdb_test_multiple.
Some weren't changed because they didn't meet the criteria above, or
weren't trivial to check.
GDB: testsuite: C++: Don't return value from top-level (manual)
This patch manually changes "return -1" and "return 0" statements that
weren't caught by the sed command.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside block such as save_vars,
with_test_prefix, foreach, gdb_test_multiple.
Some weren't changed because they didn't meet the criteria above, or
weren't trivial to check.
GDB: testsuite: base: Don't return value from top-level (manual)
This patch manually changes "return -1" and "return 0" statements that
weren't caught by the sed command.
These return statements fall into one of these criteria:
- misaligned line, which is then fixed by this patch;
- return at top level but inside a block such as save_vars,
with_test_prefix, foreach, gdb_test_multiple.
Some weren't changed because they didn't meet the criteria above, or
weren't trivial to check.
There was also one return statement with an unnecessary semi-colon at
the end, which was removed.
GDB: testsuite: riscv: Don't return value from top-level (manual)
This patch manually changes the "return -1" and "return 0" statements
that weren't caught by the sed command.
This happened only in one testcase due to the statements being inside a
foreach_with_prefix block, and in the others because the return
statement was in a misaligned line, which is now fixed.
GDB: testsuite: powerpc: Don't return value from top-level (manual)
This patch manually changes the "return -1" statements that weren't
caught by the sed command because they were in a misaligned line, which
is then aligned by this patch.
GDB: testsuite: aarch64, arm: Don't return value from top-level (manual)
This patch manually changes the "return -1" statements that weren't
caught by the sed command.
In aarch64-prologue.exp and arm-cmse-sgstubs.exp, this was caused by a
misaligned line, which is now fixed.
In aarch64-mte.exp, aarch64-non-address-bits.exp,
arm-pthread_cond_timedwait-bt.exp and thumb2-it.exp this is because the
return statements have extra indentation due to being inside
with_test_prefix, save_vars or gdb_test_multiple blocks.
Tom Tromey [Wed, 8 Apr 2026 00:23:57 +0000 (18:23 -0600)]
Use file- and line-styling with throw_error
This changes some throw_error calls to apply file_name_style and
line_number_style. This patch does both at the same time because the
two styles often appear in the same message.
Tom Tromey [Wed, 8 Apr 2026 00:18:40 +0000 (18:18 -0600)]
Allow styling when using throw_* functions
The throw_* family of functions use the varargs constructor for
gdb_exception, which then calls string_vprintf. This means that
styling cannot be applied here by gdb.
This patch changes this code to use a client-supplied formatting
function. For gdbserver this remains string_vprintf, but for gdb it
now allows styling.
I did look at unifying 'error' and the throw_* functions a bit more,
but this would have meant unravelling some IPA code.
Jan Beulich [Fri, 8 May 2026 09:45:26 +0000 (11:45 +0200)]
objcopy: zap ELF visibility when localizing symbols
The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
implicitly, STV_HIDDEN or STV_INTERNAL), so we better wouldn't (entirely
silently) write out symbols violating this.
Jan Beulich [Fri, 8 May 2026 09:45:04 +0000 (11:45 +0200)]
gas/ELF: warn upon non-default visibility of local symbols
The spec explicitly precludes STB_LOCAL together with STV_PROTECTED (and,
implicity, STV_HIDDEN or STV_INTERNAL), so we better wouldn't entirely
silently write out symbols violating this.
LoongArch's tc_symbol_new_hook() simply needs dropping. If FAKE_LABEL_NAME
symbols can end up global, marking them hidden would need doing elsewhere.
There not being a need to make any testsuite adjustments suggests though
that this won't normally (ever?) happen.
ld: Append LDFLAGS to flags variable in default_ld_link
The following change is needed to fix errors trying to load the
milli.a archive for the hppa*64*-*-hpux* target when the host
system isn't hpux.
We need to create a dummy milli.a archive for this target and
append the directory of this archive to LDFLAGS.
This assumes the testsuite takes the LDFLAGS environment variable
into account. However, some tests in the ld testsuite use the
low-level `ld-link' procedure and it fails to take LDFLAGS into
account.
This change modifies the `default_ld_link' procedure to append
$LDFLAGS to the flags variable and fix the above issue.
This change potentially affects the `alpha*-*-*vms*' target but
currently no tests run for it make direct use of `ld-link'.
Suggested-by: Maciej W. Rozycki <macro@orcam.me.uk>
2026-04-27 John David Anglin <danglin@gcc.gnu.org>
ld/ChangeLog:
* testsuite/lib/ld-lib.exp (default_ld_link): Append
LDFLAGS to `flags' variable. Also use the append command
to append the board flags.
hppa64: Re-enable -gc-section support on hppa*64*-*-hpux*
The previous change to elf_hppa_final_link_relocate didn't eliminate
relocatios with invalid offsets. Here we take a different approach
to handle invalid offsets on hpux. We allocate 16 bytes at the start
of the .data section for the linker. If we encounter a relocation
with an invalid offset, we set the relocation's offset to the start
of the data section. As a result, the HP dynamic linker is happy
and we can re-enable -gc-section support.
2026-05-07 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf_hppa_final_link_relocate): Rework
handling of relocations with invalid offsets on hpux.
(elf_backend_can_gc_sections): Set to one on hpux.
Pedro Alves [Fri, 2 Jun 2023 22:08:49 +0000 (23:08 +0100)]
Windows gdb: Avoid hang second attach/run
gdb.base/attach.exp starts a second inferior and tries to attach the
second inferior to the same process that inferior 1 is already
debugging. The point is to make sure that the backend errors out when
it tries to attach to a process that is already being debugged.
windows_nat_target::attach and windows_nat_target::create_inferior
both hang in this situation, because they call into do_synchronously,
which hangs because the 'process_thread' thread is blocked in
WaitForDebugEvent.
E.g.:
attach 4420
FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again (timeout)
Until the Windows backend is taught to debug multiple processes, which
will probably require having one process_thread thread per inferior,
detect the situation and error out before GDB hangs.
This results in the following progression in gdb.base/attach.exp:
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again (timeout)
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: set confirm off (timeout)
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1 (timeout)
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures (timeout)
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: gdb_breakpoint: set breakpoint at main (timeout)
-FAIL: gdb.base/attach.exp: do_attach_failure_tests: stop at main (timeout)
+PASS: gdb.base/attach.exp: do_attach_failure_tests: fail to attach again
+PASS: gdb.base/attach.exp: do_attach_failure_tests: set confirm off
+PASS: gdb.base/attach.exp: do_attach_failure_tests: switch to inferior 1
+PASS: gdb.base/attach.exp: do_attach_failure_tests: exit after attach failures
+PASS: gdb.base/attach.exp: do_attach_failure_tests: stop at main
There are still other failures not addressed by this patch.
Tests that launch a second program with "run" exist, but are normally
gated by allow_multi_inferior_tests.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I55b4438795439673c49fa55f55ddf0191f4f0ea8
commit-id: 1caa5be0
Pedro Alves [Fri, 5 May 2023 14:51:31 +0000 (15:51 +0100)]
Windows gdb: all-stop, interrupt with "stopped" instead of SIGTRAP
Currently, "interrupt" uses DebugBreakProcess (or equivalent), which
injects a new thread in the inferior that executes an int3 instruction
(on x86), which raises a SIGTRAP. With the target backend in non-stop
mode, its easy to avoid all that and make interrupt in all-stop just
suspend a pre-existing thread and report "stopped", like "set non-stop
on" does (via target_stop).
Thread 8 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 1180.0x1010]
0x00007ffa57490b71 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
info threads
Id Target Id Frame
1 Thread 1180.0x1374 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
2 Thread 1180.0xc3c 0x00007ffa57490ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
3 Thread 1180.0x6ec 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
7 Thread 1180.0xdc0 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
* 8 Thread 1180.0x1010 0x00007ffa57490b71 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
(gdb)
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 5912.0x394 (running)
2 Thread 5912.0x608 (running)
3 Thread 5912.0x1704 (running)
10 Thread 5912.0x870 (running)
(gdb)
...
[Thread 5912.0x870 exited with code 0]
...
(gdb) interrupt
(gdb)
Thread 1 stopped.
0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
info threads
Id Target Id Frame
* 1 Thread 5912.0x394 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
2 Thread 5912.0x608 0x00007ffa57490ad4 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
3 Thread 5912.0x1704 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
8 Thread 5912.0x1200 0x00007ffa5748d6e4 in ntdll!ZwDelayExecution () from C:\Windows\SYSTEM32\ntdll.dll
(gdb)
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I569fc69392ce9a070a2ebe1003388b7386412b14
commit-id: 8f6b76d2
Nick Clifton [Thu, 7 May 2026 09:53:46 +0000 (10:53 +0100)]
Update the SECURITY.txt document. Clarify what is meant by a "direct compromise of security", emphasise that the tools do not provide a sevrice of any kind, and show that bugs that rely upon untrusted input must be able to cross a trust boundary in order to be considered as a security issue.
hppa64: Disable -gc-section support on hppa*64*-*-hpux*
The HP-UX dynamic linker on hppa generates an error if it detects
a dynamic relocation with the R_PARISC_NONE type. As a result,
there is no way to handle relocations in sections that are garbage
collected. Although these can mostly be avoided, I think it best
to disable -gc-section support.
2026-05-06 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf_hppa_final_link_relocate): Rework
BFD_ASSERT to only trigger on hpux. Zero rela if the
new offset is invalid.
(elf_backend_can_gc_sections): Set to zero on hpux.
gdb/dwarf: Use the function scope for DW_TAG_imported_declaration
All Fortran imported variable aliases (`use module, alias => var`)
were being added to "global scope", regardless of whether they appeared
in:
- Program/module scope (should be global)
- Function scope (should be local)
This caused conflicts when different functions had the same alias name
pointing to different variables.
DW_TAG_imported_declaration and DW_TAG_namespace cases are now handled
separately. This patch modifies the case for DW_TAG_imported_
declaration in the function new_symbol () to use cu->list_in_scope
instead of global symbols for all languages. This ensures that
function-scoped aliases use the current scope rather than being forced
into the global scope.
Bug Scenario:
subroutine sub1
use mod1, var_i_alias=>var_i ! alias points to mod1::var_i
var_i_alias = 3
var_i = 4
end subroutine
subroutine sub2
use mod2, var_i_alias=>var_i ! alias points to mod2::var_i
var_i_alias = 23
var_i = 25
end subroutine
Before: var_i_alias in sub2 incorrectly resolved to mod1::var_i
(value 25)
After: Each function's alias correctly resolves to its own imported
variable (value 23)
New test files verify the fix and include regression tests for global
program-scope imports:
- gdb/testsuite/gdb.fortran/module_declarations.exp
- gdb/testsuite/gdb.fortran/module_declarations.f90
Before the change:
(gdb) print var_i_alias
$4 = 25
FAIL: gdb.fortran/module_declarations.exp: sub2_test: print var_i_alias
After the change:
(gdb) print var_i_alias
$4 = 23
PASS: gdb.fortran/module_declarations.exp: sub2_test: print var_i_alias
gdb: fix for 'set suppress-cli-notifications on' missed case
I spotted this message in the gdb.mi/user-selected-context-sync.exp
test script:
# Idea for the future: selecting a thread in a different inferior. For now,
# GDB doesn't show an inferior switch, but if it did, it would be a nice
# place to test it.
What this message is talking about is this behaviour:
(gdb) info threads
Id Target Id Frame
1.1 Thread 0xf7dbc700 (LWP 818430) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
1.2 Thread 0xf7dbbb40 (LWP 818433) "thr" 0xf7fd0579 in __kernel_vsyscall ()
1.3 Thread 0xf73ffb40 (LWP 818434) "thr" breakpt () at thr.c:19
2.1 Thread 0xf7dbc700 (LWP 818456) "thr" 0xf7eb2888 in clone () from /lib/libc.so.6
2.2 Thread 0xf7dbbb40 (LWP 818457) "thr" breakpt () at thr.c:19
* 2.3 Thread 0xf73ffb40 (LWP 818458) "thr" breakpt () at thr.c:19
(gdb) inferior 1
[Switching to inferior 1 [process 818430] (/home/andrew/tmp/thr)]
[Switching to thread 1.1 (Thread 0xf7dbc700 (LWP 818430))]
#0 0xf7eb2888 in clone () from /lib/libc.so.6
(gdb) thread 2.2
[Switching to thread 2.2 (Thread 0xf7dbbb40 (LWP 818457))]
#0 breakpt () at thr.c:19
19 while (stop)
(gdb)
Notice that when we switch from thread 2.3 to 1.1 using the 'inferior
1' command, GDB tells us that the inferior has changed, and that the
thread has changed (and also that the frame has changed).
But, when we switch from 1.1 to 2.2 using the 'thread 2.2' command, we
are only told about the thread change.
The 'Switching to inferior ...' line includes some useful information,
the process PID and the executable name, and I think it is a shame
that these are not presented when using the 'thread' command to switch
inferior.
So, this commit addresses this issue.
A question that came up during review, and which I'm clarifying here:
this change only affects the output of GDB when the thread command is
also used to switch inferiors. I am (in effect) arguing that the
command 'thread 2.2' should be treated as a shorthand for 'inferior 2;
thread 2', and should display all of the associated output. If the
user is only switching threads within a single inferior then it is not
necessary to re-display the inferior information.
I acknowledge that this does mean the output of the 'thread' command
will now be different depending on whether the user changes inferior
or not. However, I think this is better than the alternative, having
the 'thread' command always re-print the inferior information. I
think this would introduce excess noise that is not useful.
There are changes in basically two areas. The easy part is in
thread_command (thread.c). Here we spot when the inferior has changed
as a result of the 'thread' command, and include
USER_SELECTED_INFERIOR in the set of state passed to the
notify_user_selected_context_changed function.
The change in mi/mi-main.c is a little more involved. In the
mi_cmd_execute function we use an instance of user_selected_context to
spot if any inferior state (frame, thread, or inferior) changes after
an MI command, this is then used to decide if there should be a call
to interps_notify_user_selected_context_changed.
First, by calling interps_notify_user_selected_context_changed
directly, instead of notify_user_selected_context_changed, we fail to
trigger the Python selected_context event, which feels like a
mistake. If the context is changed via an MI command, I think we
should still trigger the Python event. So the first thing I did was
change the interps_notify_user_selected_context_changed call into a
call to notify_user_selected_context_changed. I updated the
gdb.python/py-selected-context.exp test to cover this case.
After that, in mi_cmd_execute, notify_user_selected_context_changed is
always passed 'USER_SELECTED_THREAD | USER_SELECTED_FRAME'. This
makes sense, the MI doesn't allow "switching inferiors" as a command,
instead, an MI frontend must switch threads, and the inferior is
switched as a consequence. But this does mean that if a user has a
CLI and MI interpreter running, and the MI switches threads, the CLI
will only receive the thread switch style notifications, that is,
there will be no "Switching to inferior ..." line.
What I've done is rename user_selected_context::has_changed to
user_selected_context::what_changed, this function is now responsible
for returning the set of USER_SELECTED_* flags that indicate what
changed.
If anything has changed then we always return USER_SELECTED_THREAD |
USER_SELECTED_FRAME as a minimum. This retains the existing
behaviour, but is possibly more aggressive than we need to be; the
-stack-select-frame command can only change the frame, so maybe in
this case we should only return USER_SELECTED_FRAME? I've left that
for the future though.
However, the important change is that in ::what_changed, I now spot
when the inferior has changed and include USER_SELECTED_INFERIOR in
the set of flags that are returned.
In mi_cmd_execute we now call the new what_changed function, and use
the set of flags returned when calling
notify_user_selected_context_changed. This means that the CLI will
now receive inferior changed notifications when appropriate.
The gdb.mi/user-selected-context-sync.exp script has been updated,
replacing the comment I quoted above with an actual test that the
inferior change is announced correctly.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Abdul Basit Ijaz [Tue, 14 Apr 2026 21:23:51 +0000 (23:23 +0200)]
gdb, fortran: Fix local variable lookup in Fortran parser
This change fixes https://sourceware.org/bugzilla/show_bug.cgi?id=34059.
The Fortran expression parser in GDB ("gdb/f-exp.y") previously performed
symbol lookup in this order when parsing identifiers:
- SEARCH_STRUCT_DOMAIN (types/structs)
- SEARCH_VFT ("C-like" name lookups for variables/types/functions)
- SEARCH_MODULE_DOMAIN (modules)
It searched for "types before variables", causing type names from shared
libraries to shadow local variable names.
For a reproducer like the one given below, the Fortran parser fails to
look up local variable name "array" and treats it as a type value instead
of a variable, because there's a conflicting "array" type from system
libraries.
1 program test
2
3 ! Declare variables used in this test.
4 integer, dimension (-2:2) :: array
5
6 array = 1
7
8 print *, "" ! Break here
9 print *, array
10
11 end program test
Before the change, GDB shows:
'''
./gdb --data-directory=./data-directory --args /tmp/a.out
GNU gdb (GDB) 18.0.50.20260408-git
Copyright (C) 2026 Free Software Foundation, Inc.
...
Reading symbols from /tmp/a.out...
(gdb) break 8
Breakpoint 1 at 0x11b3: file test.f90, line 8.
(gdb) run
Starting program: /tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, test () at test.f90:8
8 print *, "" ! Break here
(gdb) info locals
array = (1, 1, 1, 1, 1)
(gdb) print array
Attempt to use a type name as an expression
(gdb) ptype array
type = Type array
Type, C_Union :: :: u
PTR TO -> ( char :: scratch(0:15 ))
End Type array
'''
This issue is fixed in the Fortran expression parser in GDB ("gdb/f-exp.y")
by prioritizing SEARCH_VFT over other search domains during symbol lookup.
After the change, the 'array' variable is resolved to the correct value.
Mark Wielaard [Sat, 2 May 2026 16:56:52 +0000 (18:56 +0200)]
ld: Fix calls to strchr that discard or use wrong const qualifiers
* ld/emultempl/pe.em (pe_fixup_stdcalls): Make at a const char *.
(gldEMULATION_NAME_after_open): Make pnt a const char *.
(gldEMULATION_NAME_place_orphan): Make dollar a const char *.
* ld/emultempl/pep.em (pep_fixup_stdcalls): Make at a
const char *. Introduce at2 as non-const char *.
(gldEMULATION_NAME_after_open): Make pnt a const char *.
(gldEMULATION_NAME_place_orphan): Make dollar a const char *.
* ld/emultempl/spuelf.em (spu_elf_load_ovl_mgr): Make p a
const char *. Introduce np as char *.
* ld/ldelf.c (ldelf_search_needed): Call strchr on freeme, so
slash is non-const, then assign freeme to replacement.
Alan Modra [Sun, 3 May 2026 11:36:37 +0000 (21:06 +0930)]
Simplify elf64_alpha_relocate_section
Prior to Nick implementing _bfd_elf_make_dynamic_reloc_section, alpha
made no use of elf_section_data(sec)->sreloc to store the dynamic
relocation section associated with sec. After commit 83bac4b01082 the
elf_section_data was set but not used in relocate_section.
* elf64-alpha.c (elf64_alpha_relocate_section): Use
elf_section_data to get dynamic relocation section associated
with the input section.
projects / thirdparty / binutils-gdb.git / log
