Andrew Burgess [Fri, 24 Oct 2025 21:14:56 +0000 (22:14 +0100)]
gdb/testsuite: fix git repository check in gdb.src/pre-commit.exp
In the recently added gdb.src/pre-commit.exp test, we check if the
source directory is a git repository like this:
if {![file isdirectory $repodir/.git]} {
unsupported "Not in a git repository"
return
}
I make extensive use of git worktrees for development. In a worktree
.git is a file containing the location of the actual .git directory,
it is not itself a directory. As such, the above check fails,
claiming my source tree is not a git repository, when in fact, it is.
Fix this by relaxing the check to 'file exists $repodir/.git', which
will cover the directory and file case.
Haochen Jiang [Fri, 24 Oct 2025 05:49:20 +0000 (13:49 +0800)]
x86: Disable AMX-TRANSPOSE by default
In Binutils, we choose to keep the AMX-TRANSPOSE support for
now in case there are vendors want to utilize the instructions
although the feature itself is de-published. AMX-TRANSPOSE will
not show up on any Intel/AMD hardware. Also in foreseeable future,
no hardware will support AMX-TRANSPOSE, we will disable it by
default.
The patch (the removal) was done on the wrong assumption that
it was only the APX-promoted forms which would be dropped
because the APX spec was updated ahead of ISE and there was no
info that AMX-TRANSPOSE would be de-published at that time.
Given the current situation, since we will choose to disable
AMX-TRANSPOSE but not to remove the support in Binutils, we will
also not remove the APX support.
Simon Marchi [Mon, 27 Oct 2025 19:41:51 +0000 (15:41 -0400)]
gdb/solib-rocm: avoid expensive gdbarch_from_bfd call in rocm_solib_relocate_section_addresses
Loading a library containing a lot (> 100k) sections proved very slow
with whenever the support for ROCm was built into gdb. The culprit is
the gdbarch_from_bfd call in rocm_solib_relocate_section_addresses:
if (!is_amdgpu_arch (gdbarch_from_bfd (so.abfd.get ())))
This function gets called for every section, and gdbarch_from_bfd is
somewhat slow. It turns out that we can skip the gdbarch_from_bfd call,
since all is_amdgpu_arch needs is the bfd_architecture value, which we
can directly extract from the `bfd *`, without going through the
gdbarch.
Add an overload of is_amdgpu_arch that takes a `bfd *`, and use it in
rocm_solib_relocate_section_addresses.
Update a call site in rocm_solib_bfd_open to use the new overload as
well. That call site is not as much in a hot path, but there is no
point in paying the extra cost of looking up the gdbarch there. I
removed the other assert that checked that gdbarch_from_bfd returned a
non-nullptr value. If that was the case, something would be very wrong
with ROCgdb, and the problem would manifest very soon after anyway.
Change-Id: I55e9e68af59903b1b9727ff57388f9469d0e0002 Approved-by: Lancelot Six <lancelot.six@amd.com> (AMDGPU)
Tom Tromey [Wed, 22 Oct 2025 14:04:12 +0000 (08:04 -0600)]
Emit language and encoding names from dwarf-to-dwarf-assembler
This changes dwarf-to-dwarf-assembler to emit DW_LANG_* and DW_ATE_*
names when decoding the appropriate attributes. This makes the output
a little more readable and a little closer to something we'd check in.
Tom Tromey [Wed, 22 Oct 2025 13:33:35 +0000 (07:33 -0600)]
Fix formatting of attributes in dwarf-to-dwarf-assembler output
This updates dwarf-to-dwarf-assembler.py to reflect the changes made
to how attributes are parsed; see commit c44edec047d (Make location
expressions be code in DWARF assembler).
Sébastien Darche [Thu, 16 Oct 2025 21:01:10 +0000 (17:01 -0400)]
gdb: assign a valid section in convert_address_location_to_sals
The convert_address_location_to_sals function builds a symtab_and_line
from an explicit pc. Unless overlay debugging is enabled, the sal does not
contain a valid section (as find_pc_overlay will simply return nullptr).
While it is usually not a problem (as the sal users often recompute the
proper section, when needed), it may lead to the proper gdbarch not
being assigned when setting a breakpoint.
In code_breakpoint::add_location, gdb attempts to retrieve the gdbarch
through get_sal_arch by checking for the section or the symtab. However,
neither are currently set by cinvert_address_location_to_sals if the
debug symbols cannot be found. We then fall back to the current
architecture, which may cause errors in heterogeneous programs
(in ROCm, a breakpoint was not being hit since GDB was setting an
x86 int3 instruction instead of the architecture-appropriate s_trap 1).
This is a rework of a patch that was approved, but never merged
upstream (https://inbox.sourceware.org/gdb-patches/20241108195257.485488-2-lancelot.six@amd.com/).
The original change proposed to set the objfile field in the sal, and
check this field in get_sal_arch() if neither the section, nor the
symtab is defined. This patch makes GDB compute the section from the pc
instead of checking from the objfile in get_sal_arch, in accordance with
the rule of trying to set the section when creating the sal implemented
in this patch series. The test cases from the original patch are
included in this new one.
This should have minimal impact on other parts of GDB as users of this
section field would either (1) recompute it the same way (2) not use it
at all. In the case of overlay debugging, then the preceding call to
find_pc_overlay would likely assign a section.
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com> Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I23cef6ad5a66f696536c7c49c885a074bfea9b23
gdb: pass minsym section to find_function_start_sal, when possible
We may rely on a minimal symbol to place a breakpoint on a function,
for instance when debug infos are unavailable. The minsym_found
function attempts to convert that minsym to a sal using either
find_function_start_sal or filling a sal manually from the minimal
symbol. This patch implements the decision to make it the responsibility
of the sal creation site to properly fill out the section field when
that is possible.
The function address may be updated when dealing with ifuncs, which
means the section from the minsym may be completely different from the
actual function address's section. A preceding change (6f7ad238 : gdb:
ensure bp_location::section is set correct to avoid an assert) has
proposed recomputing the section by calling find_pc_overlay. However,
this ends up setting the section to NULL in most cases. While the
section is often recomputed later on, I think it might be more
appropriate to set it once and for all when creating the sal.
The parent commit ensures that find_function_start_sal will return a
symtab_and_line with a section if possible. minsym_found can pass the
section if it can be trusted later on - it is in fact necessary to
ensure we get the proper pc/section with overlays. When dealing with
an ifunc that was resolved, then the section has to be recomputed
since the ifunc implementation may be in another section, or objfile.
This is now done in find_sal_for_pc_sect.
This change restores the section argument in
find_function_start_sal that was removed in a previous commit (6b0581fc
: gdb/symtab: remove section parameter from find_function_start_sal),
as it avoids an unnecessary lookup later in find_sal_for_pc_sect. The
function now sends the minsym's section if it corresponds to the actual
function, and not an ifunc.
This commit fixes a failure on gdb.rocm/displaced-stepping.exp. A new
test case is also provided to check that a breakpoint on a kernel is hit
without debug infos.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I7a502dc4565911cec92618f34be3d4bcbf8560c5
gdb: make find_sal_for_pc_sect attempt to fill sal section
The find_sal_for_pc_section function inconsistently fills the section
field from its output symtab_and_line, depending on whether a symtab is
present or not. In the case that we cannot find a symtab for the pc and
section, the function would construct a sal with a pc but no section,
even though it could be either forwarded from the arguments, or
computed from the pc.
With the proposed changes, the function attempts to set the section in
all code paths and performs a section lookup when it is not provided as
an argument. This change is part of a patch series to fix
inconsistencies in symtab_and_line constructions, making it the
responsibility of the sal creator to fill out the section field (when
possible).
This section may be passed from a minsym in an unmapped overlay section.
Leaving the section field empty would mean in most cases losing some
important context (e.g. which overlay section this pc corresponds to).
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I818a08c4f61803b6d2cadd32ec106fe416af4c66
Sébastien Darche [Mon, 20 Oct 2025 19:07:33 +0000 (15:07 -0400)]
gdb: lookup minsym using section in find_sal_for_pc_sect
The find_sal_for_pc_sect function attempts to find the line that is
closest to a pc+section in the available symbols. One of the first thing
the function does is search for a bound minimal symbol corresponding to
that pc. In its original version, the lookup is performed by
lookup_minimal_symbol_by_pc, discarding the section. This is misleading
and may cause issues with overlay debugging if a second minsym with the
same pc (but a different section) can be found -- although this is only
in theory after inspecting the code, as I have no way to test this on a
system supporting overlays.
This should have no observable effects for the end user. One slight
benefit is that we can avoid a section lookup inside
lookup_minimal_symbol_by_pc_section if the caller does provide a
section.
Since the section is already passed as an argument to the function, the
proposed change forwards this section to the minsym lookup section.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I86a16bf397ea7167d3e9c7db79b8d7901fad1a97
Simon Marchi [Mon, 27 Oct 2025 19:12:24 +0000 (15:12 -0400)]
gdb/dwarf: make some fields of dwarf2_per_cu private
The comments on these fields mention that they should be private, but we
can't. I think this comes from the time where dwarf2_per_cu was and had
to remain POD. I don't think it's relevant anymore, there are other
private fields anyway. Make them private.
Change-Id: I1915ea531f42d685f68ff547833816906f79cd58 Approved-By: Tom Tromey <tom@tromey.com>
Guinevere Larsen [Fri, 24 Oct 2025 11:43:46 +0000 (08:43 -0300)]
gdb/help: Update help message for target record-core
Before this commit, the help message for target record-core is the same
as the help message for target record-full, which is the following:
Log program while executing and replay execution from log.
For one, having the same message is unhelpful, since it doesn't tell
users what the difference between the two is. But, more importantly,
that message seems to also be incorrect, since attempting to execute the
inferior forward from a restored file past the end of history will crash
GDB, since there isn't an actual live inferior to run.
To fix this, the help text is updated to the following:
Load a saved execution log, allowing replay of the last instructions
This message doesn't imply that future execution is supported, while it
shows that replaying within recorded instructions *is* supported.
The dot prefix used for R_PARISC_EPLT relocations causes issues
for symbol version support as no version section is defined for
these symbols. This causes the linker to exit with an error.
This change modifies the handling of EPLT relocations to use
offsets relative to a __text_seg base symbol. This symbol is
defined in the same way as the HP linker (a section symbol for
the .dynamic section).
This mostly fixes the symbol versioning support. There are
still issues caused by the munging of the value and section
of dynamic symbols. The value modifies the sorting of the
dynamic table by number. The section changes the type of
text symbols to data symbols. I don't think the section munging
is actually needed but that's an issue for another patch.
2025-10-26 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (USE_DOT_ELPT_PREFIX): Define.
(struct elf_link_hash_entry): Add text_segment field.
(allocate_global_data_opd): Compute hppa_info.
Condition old dot prefix code on USE_DOT_ELPT_PREFIX.
Add new code to setup __text_seg hash table entry.
(elf64_hppa_finalize_opd): Check hh. Rework to output
relocation using __text_seg base.
(elf64_hppa_finish_dynamic_sections): Remove duplicate
comment.
(elf_hppa_final_link_relocate): Move code to initialize
the segment base values forward.
BFD: Fix function prototype breakage through stabs.c
Update function prototype templates through stabs.c according to commit eb92a17c47ea ("bfd: move sec_info from ELF to general section struct"),
which changed the generated prototypes in libbfd.h by hand rather than
by remaking them properly from sources, and causing the build to fail as
soon as libbfd.h has been regenerated.
While at it remove an extraneous character introduced by the same commit
to a comment for a new member of `struct bfd_section'.
Guinevere Larsen [Thu, 23 Oct 2025 18:05:33 +0000 (15:05 -0300)]
gdb/reverse: update error message for "reverse-" commands
Before this change, when a user tried to use a command that executes the
inferior in reverse, they would get the following error message:
Target multi-thread does not support this command.
As an end-user with no knowledge of the internals of GDB would have as a
best guess, that reverse execution as a whole would not be supported in
their system (verified by asking a couple new users).
This commit changes the message to avoid the internal terminology, and
to add a hint that the user may need to create a recording somehow to be
able to execute in reverse.
Tom Tromey [Tue, 14 Oct 2025 19:26:30 +0000 (13:26 -0600)]
Handle dynamic DW_AT_bit_size
gnat-llvm will sometimes emit a structure that that uses
DW_AT_bit_size with an expression to compute the bit size of a record.
I believe this is a DWARF extension. This patch implements support
for this in gdb.
Simon Marchi [Thu, 23 Oct 2025 16:34:23 +0000 (12:34 -0400)]
gdb: add gdb_rl_tilde_expand util
Add gdb_rl_tilde_expand, a wrapper around readline's tilde_expand that
returns a gdb::unique_xmalloc_ptr<char>. Change all callers of
tilde_expand to use gdb_rl_tilde_expand (even the couple of spots that
release it immediatly, for consistency). This simplifies a few callers.
The name gdb_tilde_expand is already taken by a home-made implementation
in gdbsupport/gdb_tilde_expand.{h.cc}. I wonder if we could just use
that one instead of readline's tilde_expand, but that's an orthogonal
question. I don't know how they differ, and I don't want to introduce
behavior changes in this patch.
Change-Id: I6d34eef19f86473226df4ae56d07dc01912e3131 Approved-By: Tom Tromey <tom@tromey.com>
Rainer Orth [Fri, 24 Oct 2025 13:57:24 +0000 (15:57 +0200)]
ld: testsuite: xfail ld-elf/compress1a etc. on Solaris/sparcv9 [PR25802]
A couple of tests FAIL on Solaris/sparcv9:
FAIL: ld-elf/compress1a
FAIL: ld-elf/compressed1a
FAIL: ld-elf/eh5
FAIL: --gc-sections with multiple debug sections for a function section
The symptom is always similar:
compress1.o:(.debug_info+0x10): relocation truncated to fit: R_SPARC_UA32 against `.text'
eh5.o:(.eh_frame+0x3e): relocation truncated to fit: R_SPARC_UA32 against symbol `my_personality_v0' defined in .text section in eh5.o
all-debug-sections.o: in function `debug_info_main':
(.debug_info.text.main+0x4): relocation truncated to fit: R_SPARC_32 against symbol `main' defined in .text.main section in all-debug-sections.o
With the default Solaris/sparcv9 text address of 0x100000000, the
relocations are out of the 32-bit range of R_SPARC_UA32 resp. R_SPARC_32,
so the "relocation truncated to fit" errors are benign.
One could avoid those by linking the affected tests with -Ttext=0x80000000,
matching Solaris /usr/lib/ld/map.below4G, but that doesn't reflect real
usage. Therefore this patch xfail's those tests.
Tested on sparcv9-sun-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.
On openSUSE Leap 15.6 x86_64 I ran into:
....
(gdb) file gdbindex-stabs^M
Reading symbols from gdbindex-stabs...^M
warning: stabs debug information is not supported.^M
(gdb) list stabs_function^M
(gdb) FAIL: gdb.base/gdbindex-stabs.exp: list stabs_function
...
H. Peter Anvin [Fri, 24 Oct 2025 13:12:39 +0000 (15:12 +0200)]
z80, gas: follow historical assemblers and allow "op A,x" and "op x"
For arithmetic ops, Z80 syntax wants "op A,x" for ADD, ADC and SBC and
"op x" for SUB, AND, OR, XOR, and CP. Many historical assemblers
simply treat them orthogonally; allowing but not requiring the "A,"
operand for any of these operations. This is widely used in legacy
source code, and there is no reason not to.
Jan Beulich [Fri, 24 Oct 2025 13:11:39 +0000 (15:11 +0200)]
bfd: replace _bfd_merge_sections() hook with simple boolean
There's no need for a hook; what needs doing is uniform, the question is
only whether to perform any merging (i.e. whether other parts of a backend
are capable of dealing with the effects).
Where _bfd_nolink_bfd_merge_sections() was used, false is hardcoded. For
ELF no real target override is permitted; true is hardcoded except for the
cases where bfd_generic_merge_sections() was used as the hook function
before.
Jan Beulich [Fri, 24 Oct 2025 13:11:11 +0000 (15:11 +0200)]
bfd: generalize _bfd_elf_merge_sections()
Except for the ELF class check, which isn't needed anymore when the
generic linker knows how to deal with SEC_MERGE sections, there isn't
anything substantially ELF-specific left in the function.
This also eliminates the need for the "remove_hook" callback.
As a result, section merging itself now works for mixed-class ELF input
objects (issues with dropping of symbols and relocations that were there
before for such cases remain present, though), i.e. the PR ld/19013
testcases need adjusting accordingly: Both now expect identical .rodata
contents. While making the change, add another line of expected output,
to properly match after "#...". Else a mismatch on the important line
isn't properly visible in ld.log.
In set_symbol_from_hash() additionally set BSF_GLOBAL when dealing with a
defined symbol. Without that the if() body ahead of the one being added to
default_indirect_link_order() would not be entered once previously
undefined symbols become defined (suggesting that there is a pre-existing
issue there).
... as well as that of _bfd_stab_section_offset(): As sec_info is now
hanging off of sec, there's no need for the extra 4th parameter anymore.
Along these line struct struct coff_section_tdata's stab_info member then
isn't needed anymore either.
Furthermore there also hasn't been a good reason to have the caller of
_bfd_link_section_stabs() set sec_info_type.
As sec_info is now hanging off of sec, there's no need for the extra 3rd
parameter anymore; all callers pass as 2nd argument the address of a
section pointer that sec_info can be fetched from.
As sec_info is now hanging off of sec, there's no need for the extra 4th /
3rd parameter anymore. Along these line struct sec_merge_sec_info's
psecinfo member then isn't needed anymore either.
Furthermore there also hasn't been a good reason to have the caller of
_bfd_add_merge_section() set sec_info_type.
Jan Beulich [Fri, 24 Oct 2025 13:09:11 +0000 (15:09 +0200)]
bfd: move sec_info from ELF to general section struct
This is in preparation of supporting section merging also when the output
isn't ELF (or not of the same class). Note that it's also more consistent
this way, as the related sec_info_type field also live in the same struct.
Tom Tromey [Fri, 24 Oct 2025 00:04:14 +0000 (18:04 -0600)]
Remove get_context_stack_depth
Nothing calls get_context_stack_depth, so this patch removes it.
I looked at also removing context_stack::depth but apparently this is
used in coffread.c, and I didn't want to figure out how to make it
local to just that code.
This patch removes buildsym_compunit::end_compunit_symtab_with_blockvector.
This method is only called in one spot and the two methods can easily
be combined.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Vrany [Thu, 23 Oct 2025 19:39:44 +0000 (20:39 +0100)]
gdb: change find_pcs_for_symtab_line() to return entries instead of PCs
This commit changes find_pcs_for_symtab_line() to return complete
linetable entries instead of just PCs. This is a preparation for adding
more attributes to gdb.LinetableEntry objects.
I also renamed the function to find_linetable_entries_for_symtab_line()
to better reflect what it does.
Tom Tromey [Fri, 17 Oct 2025 17:23:38 +0000 (11:23 -0600)]
Free multidicts from blockvector
Currently, nothing in the tree ever calls mdict_free. However, code
does heap-allocate some multidicts. A simple way to see this is to
use valgrind, run "gdb -readnow" on the executable created by
gdb.dwarf2/struct-with-sig.exp, and then use "file" to clear the
objfile list. This yields:
==1522843== 144 (16 direct, 128 indirect) bytes in 1 blocks are definitely lost in loss record 905 of 3,005
==1522843== at 0x4843866: malloc (vg_replace_malloc.c:446)
==1522843== by 0x48E397: xmalloc (alloc.c:52)
==1522843== by 0x59DE66: multidictionary* xnew<multidictionary>() (poison.h:102)
==1522843== by 0x59CFF4: mdict_create_hashed_expandable(language) (dictionary.c:965)
==1522843== by 0x50A269: buildsym_compunit::finish_block_internal(symbol*, pending**, pending_block*, dynamic_prop const*, unsigned long, unsigned long, int, int) (buildsym.c:221)
==1522843== by 0x50AE04: buildsym_compunit::end_compunit_symtab_get_static_block(unsigned long, int, int) (buildsym.c:818)
==1522843== by 0x50C4CF: buildsym_compunit::end_expandable_symtab(unsigned long) (buildsym.c:1037)
==1522843== by 0x61DBC6: process_full_type_unit (read.c:4970)
This patch fixes the leaks by calling mdict_free when a blockvector is
destroyed.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Fri, 17 Oct 2025 17:21:50 +0000 (11:21 -0600)]
Two bug fixes in mdict_free
A heap-allocated multidictionary should be freed by calling
mdict_free. However, while this function does free the contents of
the dictionary, it neglects to free the dictionary itself.
There's also a second bug, which is that if a multidictionary is
created with no dictionaries, gdb will crash on the first line of
mdict_free:
enum dict_type type = mdict->dictionaries[0]->vector->type;
So, this patch also adds the type to struct multidictionary, avoiding
this problem. Note that this does not increase the structure size on
x86-64, because the new member fits into the padding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 21 Oct 2025 16:00:20 +0000 (10:00 -0600)]
Remove Python API checker defines
The GCC plugin that implements the Python API checker does not appear
to really be maintained. And, as far as I know, it never really
worked for C++ code anyway. Considering those factors, and that no
one has tried to run it in years, I think it's time to remove the
macros from the gdb source.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 21 Oct 2025 16:04:14 +0000 (10:04 -0600)]
Remove Py_TPFLAGS_CHECKTYPES
According to 'git annotate', the Py_TPFLAGS_CHECKTYPES was added to
python-internal.h way back when gdb was first ported to Python 3. It
was a compatibility fix for Python 2.
This is not needed any more, because Python 2 is no longer supported.
This patch removes the vestiges.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Jan Vrany [Thu, 23 Oct 2025 11:01:34 +0000 (12:01 +0100)]
gdb: update mdebugread.c to use blockvector::block_less_than
This commit updates mdebugread.c to use common blockvector ordering
predicate. It also changes the code to use std::stable_sort as in
buildsym.c. This is probably not necessary but should not hurt and makes
block sorting code more consistent.
Jan Vrany [Thu, 23 Oct 2025 11:01:34 +0000 (12:01 +0100)]
gdb: add block ordering predicate for ordering blocks in blockvector
This commit adds blockvector::block_less_than() predicate that defines
required ordering of blocks within blockvector.
It orders blocks so that blocks with lower start address come before
blocks with higher start address. If two blocks start at the same
address, enclosing (larger) block should come before nested (smaller)
block.
This ordering is depended upon in find_block_in_blockvector(). Although
its comment did not say so, find_block_in_blockvector() is called from
blockvector_for_pc_sect() which is explicit about it. While at it, I
changed the comment of find_block_in_blockvector() to say so explicitly
too.
As Andrew pointed out, buildsym.c sorts block slightly differently,
taking only the start address into account. The comment there says
blocks with same start address should not be reordered as they are in
correct order already and that order is needed. It is unclear to me
if buildsym.c arranges blocks starting at the same address in required
order before sorting them or this happens "by chance". I did modify
buildsym_compunit::make_blockvector() to assert blocks are properly
ordered and running testsuite did not show any regressions.
Jan Vrany [Thu, 23 Oct 2025 11:01:34 +0000 (12:01 +0100)]
gdb: use std::vector<> to hold on blocks in struct blockvector
This patch changes blockvector to be allocated on the heap (using 'new')
and changes internal implementation to use std::vector<> rather than
flexible array to add blocks to existing blockvector. This is needed for
lazy CU expansion and for Python API to build objfiles, compunits and
symtabs dynamically (similarly to JIT reader API).
The downside is higher memory consumption. The size of std::vector is
24 bytes (GCC 14) compared to 8 bytes used currently to store the number
of blocks (m_num_blocks). Stopping gdb at its main(), followed by
"maint expand-symtabs" results in 4593 compunit symtabs so in this case
the overhead is 16*4593 = 73488 bytes which I hope is acceptable.
While at it, add blockvector::append_block() to add more block at the
end of block vector. This is currently used only in mdebugread.c.
timurgol007 [Wed, 8 Oct 2025 15:44:19 +0000 (18:44 +0300)]
gdb/record: Speeding up recording in RISC-V
I measured that removing saving mem chunks and regs to std::vector before
calling API functions speeds up stepping up to 15%, so I added this
optimization (as Guinevere Larsen <guinevere@redhat.com> recommended in
initial support). It turns out that after this, the m_record_type and
m_error_occured no longer needed, so I removed them too.
Tom de Vries [Wed, 22 Oct 2025 15:32:57 +0000 (17:32 +0200)]
[gdb/testsuite] Simplify gdb.cp/local-static.exp
Simplify test-case gdb.cp/local-static.exp in the following way.
First rewrite this uplevel into a more usual form:
...
-set print_quoted_re [uplevel 1 "subst_vars \"$print_quoted_re\""]
+set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]]
...
This requires us to use "subst -nocommands" instead of subst_vars, to allow
backslash substitution, which previously was happening implicitly because of
the way uplevel was used.
Then, declare globals hex and syntax_re, such that we no longer have to use
uplevel:
...
-set print_quoted_re [uplevel 1 [list subst -nocommands $print_quoted_re]]
+set print_quoted_re [subst -nocommands $print_quoted_re]
...
Maximilian Bosch [Fri, 10 Oct 2025 09:20:42 +0000 (11:20 +0200)]
gdb: fix loading compressed scripts from `.debug_gdb_scripts`-section
The function `gdb_bfd_get_full_section_contents` doesn't implement
decompressing debug sections. This regresses loading `.debug_gdb_scripts`-section
from ELFs that were built with `-ggdb -Wa,--compress-debug-sections`
giving the following warnings on load:
Tom de Vries [Wed, 22 Oct 2025 05:36:07 +0000 (07:36 +0200)]
[gdb/testsuite] Add proc subst_vars
Add proc subst_vars, an alias of subst -nobackslashes -nocommands.
I've used tailcall to implement this:
...
proc subst_vars { str } {
tailcall subst -nobackslashes -nocommands $str
}
...
but I found that this also works:
...
proc subst_vars { str } {
return [uplevel 1 [list subst -nobackslashes -nocommands $str]]
}
...
I've found other uses of subst that don't add "-nobackslashes -nocommands",
but really only use subst to do variable substitution. Also use subst_vars in
those cases.
Tom de Vries [Wed, 22 Oct 2025 05:28:45 +0000 (07:28 +0200)]
[gdb/contrib] Handle unknown attribute in dwarf-to-dwarf-assembler.py
I ran gdb/contrib/dwarf-to-dwarf-assembler.py on a hello world compiled with
gcc 15, and ran into:
...
Traceback (most recent call last):
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 642, in <module>
main(sys.argv)
~~~~^^^^^^^^^^
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 638, in main
generator.generate()
~~~~~~~~~~~~~~~~~~^^
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 610, in generate
self.generate_die(die, indent_count)
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 589, in generate_die
die_lines = die.format(self.dwarf_parser.offset_to_die, indent_count)
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 279, in format
return "\n".join(self.format_lines(offset_die_lookup, indent_count))
~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 376, in format_lines
inner_lines = super().format_lines(offset_die_lookup, indent_count + 1)
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 251, in format_lines
attr_line = attr.format(
offset_die_lookup, indent_count=indent_count + 1
)
File "/data/vries/gdb/./src/gdb/contrib/dwarf-to-dwarf-assembler.py", line 199, in format
s += self.name + " "
~~~~~~~~~~^~~~~
TypeError: unsupported operand type(s) for +: 'int' and 'str'
...
because of trying to print DWARF v6 attributes DW_AT_language_name (0x90) and
DW_AT_language_version (0x91).
Fix this by printing the number if the name is not known:
...
{DW_AT_0x90 3 DW_FORM_data1}
{DW_AT_0x91 202311 DW_FORM_data4}
...
Tom de Vries [Wed, 22 Oct 2025 05:28:45 +0000 (07:28 +0200)]
[gdb/contrib] Fix errno.EOPNOTSUP in dwarf-to-dwarf-assembler.py
When running dwarf-to-dwarf-assembler.py without arguments, I run into:
...
$ ./gdb/contrib/dwarf-to-dwarf-assembler.py
Usage:
python ./asm_to_dwarf_assembler.py <path/to/elf/file>
Traceback (most recent call last):
File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 621, in main
filename = argv[1]
~~~~^^^
IndexError: list index out of range
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 642, in <module>
main(sys.argv)
~~~~^^^^^^^^^^
File "/data/vries/gdb/binutils-gdb.git/./gdb/contrib/dwarf-to-dwarf-assembler.py", line 625, in main
sys.exit(errno.EOPNOTSUP)
^^^^^^^^^^^^^^^
AttributeError: module 'errno' has no attribute 'EOPNOTSUP'. Did you mean: 'EOPNOTSUPP'?
...
Pietro Monteiro [Mon, 20 Oct 2025 00:14:51 +0000 (20:14 -0400)]
objcopy: Don't add zstd to the debug compression options if not available
If zstd is not available or was intentionally disabled by the user
don't add it to the list of the available options to compress debug
sections when showing usage.
binutils/
* objcopy.c (copy_usage): Only output
--compress-debug-sections=zstd if HAVE_ZSTD.
Luis Machado [Sat, 11 Oct 2025 10:43:48 +0000 (11:43 +0100)]
AArch64: Fix SME za register description
Peter Maydell and Vacha Bhavsar pointed out that we have an incorrect
description of the SME za register in the documentation. It is currently
described as a vector of SVL x SVL bytes, but that is incorrect.
What we really have is a 2-dimensional array of bytes, with each dimension
having size SVL.
LD/testsuite: Add tests for mapless archive rejection
Verify that archives are rejected in the link, regular and thin, that
have no symbol map included. Exclude XCOFF targets from verification
which have handling for such archives implemented and therefore accept
them. These targets will be handled with a follow-up change.
Add basic verification for archives to work, regular and thin, in the
link. Refer to PR binutils/33484 and PR binutils/33485 for targets that
fail these basic checks, where `ar' fails to add subsequent members to
the archive or fails to add symbols from subsequent members to the map
respectively, for thin archives.
NB symbol names chosen such as to avoid a clash with Z80 CPU registers.
Guinevere Larsen [Wed, 12 Feb 2025 19:07:38 +0000 (16:07 -0300)]
gdb: remove support for dbx from GDB
With the removal of stabs support, reading a dbx inferior has become a
no-op and GDB is unable to perform sybmolic debugging in such inferiors.
As such, this commit removes the files that work on it with spotty
support.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Guinevere Larsen [Wed, 12 Feb 2025 13:40:06 +0000 (10:40 -0300)]
gdb: Fully remove stabs code from GDB
This commit is the last in the series removing GDB's support for stabs.
It removes the stabsread.{c|h} files, and removes the last usage of
stabsread stuff in buildsym. Notably, the header file gdb-stabs.h
remains in the tree as it is misnamed at this point - it is used for
reading dbx objfiles. It (and dbxread) will be removed in a future
commit.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Guinevere Larsen [Wed, 29 Jan 2025 12:31:03 +0000 (09:31 -0300)]
gdb: Remove stabs support from XCOFF inferiors
This commit is the second to last in the series fully removing support
for stabs in GDB, removing it from XCOFF inferiors. According to IBM's
AIX documentation[1], xcoff binaries can only have stabs or DWARF debug
info, meaning removing stabs seems pretty trivial, as anything that
isn't related to setting base information on the objfile or reading
dwarf can be removed.
The unfortunate part of this removal is that XCOFF minimal symbols are
encoded in stabs, so if an inferior has not been compiled with dwarf
debuginfo, GDB will only be able to do assembly-level debugging. Due to
this, the xcoff reader now emits a warning if no dwarf is read, saying:
"No usable debug information found". This change would also add a lot of
regressions to to AIX, so the gdb_compile proc has been changed to not
work when a test tries to compile a test with nodebug.
As a sidenote, gdb-stabs.h can just be removed from rs6000-aix-nat, as
none of the structs or macros defined in the header are used in the nat
file, so that is an unnecessary include.
This commit introduces some known regressions when testing GDB in AIX
systems. The main ones are:
* inferior function calls now crash with a corrupted stack. This seems
to be some fault of dwarf in explaining how to correctly set the frame
for a function.
* fortran tests can't runto_main: the fortran compiler does not add any
symbol for MAIN__ in the dwarf information, only in stabs, so the
fortran_runto_main proc can't set the breakpoint correctly.
* When dealing with c++ class methods, there are cases when we fail to
properly recognize a method call as a new function.
* When dealing with c++ virtual inheritance, GDB has issues finding a
derived class's members when it has been downcast to a base class.
Guinevere Larsen [Tue, 28 Jan 2025 11:47:02 +0000 (08:47 -0300)]
gdb: Remove stabs support for COFF files
This commit continues the removal of stabs by removing support from coff
inferiors. This is trivial for the most part, just a removal of code
setting things only relevant for stabs, with one exception.
The global variables symnum and within_function were introduced to
coffread.c (and within_function was converted to boolean). I looked into
making them parameters to the relevant function, but this would require
changes to several otherwise untouched functions, so I kept them as globals
instead.
Guinevere Larsen [Mon, 27 Jan 2025 14:33:11 +0000 (11:33 -0300)]
gdb: Remove stabs support from dbx
This commit makes it so reading dbx inferiors will not read stabs
debuginfo from the inferiors.
This has the side effect of making reading DBX inferiors a noop. It
will be removed in a future commit, however, the present series of
commit is focused on just removing stabs.
Guinevere Larsen [Wed, 22 Jan 2025 17:05:01 +0000 (14:05 -0300)]
gdb: Remove stabs support from ELF files
This commit makes it so that GDB won't read stabs information from ELF
files. If stabs is detected in an ELF file, the reader now warns the user
that stabs is not supported.
This test would cause two new failures in the test gdb.stabs/weird.exp
(that surprisingly didn't happen in the mips commit). Rather than fixing
the test that'll be removed soon, I just removed the test instead.
Guinevere Larsen [Tue, 14 Jan 2025 17:28:18 +0000 (14:28 -0300)]
gdb/mdebug: Remove stabs support from mips inferiors
Ostensibly, the mdebugread.c is about reading debug information in the
ecoff format, but it also supports stabs-in-ecoff according to comments
in there, and also relied in some stabs facilities for ecoff reading
itself. This commit takes the first step in removing stabs support by
removing those dependencies from mdebug. And in order to support
stabs-in-ecoff, mipsread would also call stabsread_new_init.
Removing stabs-in-ecoff is trivial, as the code was well demarcated with
comments mentioning where stabs was read. Plus the call to
stabsread_new_init in mipsread can be trivially removed.
Another simple removal was the dependence on stabs_end_psymtabs: because
the local variables dependencies_used and includes_used were only touched
by stabs-reading code, they are always 0 in the new version, which means
we can find the exact code path that'd be followed in stabs_end_psymtab
and move the relevant lines to mdebug instead.
After all those, the last remaining dependency is when reading a fortran
common block from an inferior compiled by SGI fortran compilers (and
maybe more). The block could have no address, meaning it'd need to be
fixed after all the minimal symbols have been read. This was done by
adding the symbol to the stabs global_sym_chain, then calling
scan_file_globals to fix them up. This commit copies all the necessary
code for handling the fortran symbols onto mdebug, technically making
some code duplication, but since stabsread will be removed soon, this
shouldn't be too concerning.
This change was tested in the compile farm's mips64 machine (number
230), where it actually seems to have solved some 50 failures in the
testsuite, not including changes in tests from gdb.threads, as those are
often very racy. I'm not sure if these were true fixes or racy cases,
but since the new version has no newly introduced fails, only fewer of
them, I'm inclined to think this change is at least harmless.
Guinevere Larsen [Tue, 28 Jan 2025 18:45:10 +0000 (15:45 -0300)]
gdb: move some stabs functions to gdb/buildsym-legacy.h
The gdb/stabsread.h and .c files define 2 things that, while originally
intended only for stabs reading, actually end up being used for coff,
ecoff and maybe more debuginfo formats. That is the function "hashname",
and the macro HASHSIZE. Both are used for small hashtables when reading
some symbols with incomplete information.
With the upcoming removal of stabs code, this code should be moved
somewhere, and the location that looked most reasonable was
gdb/buildsym-legacy. No change in behavior is expected after this
commit.
Simon Marchi [Tue, 7 Oct 2025 18:42:53 +0000 (14:42 -0400)]
gdb/testsuite/gdb.python/py-symbol.exp: accept either rr static symbol when calling lookup_static_symbol
Since commit dad36cf91992 ("gdb/dwarf: use dynamic partitioning for
DWARF CU indexing"), we get the intermittent failures:
python print (gdb.lookup_static_symbol ('rr').line)
18
(gdb) FAIL: gdb.python/py-symbol.exp: print line number of rr
python print (gdb.lookup_static_symbol ('rr').value ())
99
(gdb) FAIL: gdb.python/py-symbol.exp: print value of rr
The situation is:
- The program isn't running.
- Two compilation units define a static symbol named `rr`.
- The test does:
gdb.lookup_static_symbol ('rr')
The test expects this to return one specific (out of the two) `rr`
static symbols. Since dad36cf91992, the call sometimes returns the
wrong symbol.
The documentation for gdb.lookup_static_symbol says this:
There can be multiple global symbols with static linkage with the
same name. This function will only return the first matching symbol
that it finds. Which symbol is found depends on where GDB is
currently stopped, as GDB will first search for matching symbols in
the current object file, and then search all other object files. If
the application is not yet running then GDB will search all object
files in the order they appear in the debug information.
cooked_index_functions::search searches index shards linearly and
returns the first matching symbol. Before dad36cf91992, the work was
split statically among threads, so symbols would end up in shards
deterministically. Since the first part of the debug info ends up in
the first shard, it happens to work as described in the doc.
Since dad36cf91992, symbols end up in random shards, based on which
thread happened to pop their CU from the work queue.
I don't think that specifying which of the multiple matching static
symbols is returned is really useful, as it unnecessarily restricts the
implementation. If multiple static symbols match the criteria, I think
it makes sense that you'll get an unspecified one. Code that needs to
deal with the possibility of multiple static symbols of the same name
should use gdb.lookup_static_symbols.
I propose to remove this guarantee from gdb.lookup_static_symbol. I
understand that this is a breaking change, but I think it's easy enough
to deal with it.
Update the test to accept either symbol.
Update the doc to say that an unspecified symbol will be returned if the
program is not running and there are multiple matching symbols. The
previous text also seemed a bit wrong about its use of the term "object
file". GDB searches a static symbol for the current compilation unit
first. It then falls back to searching all symbols.
Change-Id: I22f81c186b1483a488ea7614fb81fd102db3c7f1 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33518 Approved-By: Andrew Burgess <aburgess@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
William Ferreira [Sun, 12 Oct 2025 21:15:55 +0000 (18:15 -0300)]
Create script to convert old tests into Dwarf::assemble calls.
PR testsuite/32261 requests a script that could convert old .S-based
tests (that were made before dwarf.exp existed) into the new
Dwarf::assemble calls in Tcl. This commit is an initial implementation
of such a script. Python was chosen for convenience, and only relies on
a single external library.
Usage: the script operates not on .S files, but on ELF files with DWARF
information. To convert an old test, one must run said test via
`make check-gdb TESTS=testname` in their build directory. This will
produce, as a side effect, an ELF file the test used as an inferior, at
gdb/testsuite/outputs/testname/testname. This ELF file is this script's
input.
Reliability: not counting the limitations listed below, the script seems
functional enough to be worthy of discussion in the mailing list. I have
been testing it with different tests that already use Dwarf::assemble,
to see if the script can produce a similar call to it. Indeed, in most
cases that I've tested (including some more complex ones, marked with an
asterisk below) it is able to produce comparable output to the original
exp file. Of course, it can't reproduce the complex code *before* the
Dwarf::assemble call. Values calculated then are simply inlined.
The following .exp files have been tried in this way and their outputs
highly resemble the original:
- gdb.dwarf2/dynarr-ptr
- gdb.dwarf2/void-type
- gdb.dwarf2/ada-thick-pointer
- gdb.dwarf2/atomic-type
- gdb.dwarf2/dw2-entry-points (*)
- gdb.dwarf2/main-subprogram
The following .exp files work, with caveats addressed in the limitations
section below.
- gdb.dwarf2/cpp-linkage-name
- Works correctly except for one attribute of the form SPECIAL_expr.
- gdb.dwarf2/dw2-unusual-field-names
- Same as above, with two instances of SPECIAL_expr.
- gdb.dwarf2/implptr-optimized-out
- Same as above, with two instances of SPECIAL_expr.
- gdb.dwarf2/negative-data-member-location
- Same as above, with one instance of SPECIAL_expr.
The following .exp files FAIL, but that is expected:
- gdb.dwarf2/staticvirtual.exp
- high_pc and low_pc of subprogram "~S" are hardcoded in the original
.exp file, but they get replaced with a get_func_info call. Since
the function S::~S is not present in the original, get_func_info
will fail.
The following .exp files DO NOT WORK with this script:
- gdb.dwarf2/cu-no-addrs
- `aranges` not supported.
- Compile unit high_pc and low_pc hardcoded, prone to user error
due to forgetting to replace with variables.
- gdb.dwarf2/dw2-inline-stepping
- Same as above.
- gdb.dwarf2/fission-relative-dwo
- `fission` not supported.
- gdb.dwarf2/dw2-prologue-end and gdb.dwarf2/dw2-prologue-end-2
- Line tables not supported.
Currently the script has the following known limitations:
- It does not support line tables.
- It does not use $srcfile and other variables in the call to
Dwarf::assemble (since it can't know where it is safe to substitute).
- It does not support "fission" type DWARFs (in fact I still have no
clue what those are).
- It does not support cu {label LABEL} {} CUs, mostly because I couldn't
find the information using pyelftools.
- It sometimes outputs empty CUs at the start and end of the call. This
might be a problem with my machine, but I've checked with DWARF dumps
and they are indeed in the input ELF files generated by
`make check-gdb`.
- It does not support attributes with the forms DW_FORM_block* and
DW_FORM_exprloc. This is mostly not a concern of the difficulty of
the implementation, but of it being an incomplete feature and, thus,
more susceptible to users forgetting to correct its mistakes or
unfinished values (please see discussion started by Guinevere at
comment 23 https://sourceware.org/bugzilla/show_bug.cgi?id=32261#c23).
The incompleteness of this feature is easy to demonstrate: any call to
gdb_target_symbol, a common tool used in these attributes, needs a
symbol name that is erased after compilation. There is no way to guess
where that address being referenced in a DW_OP_addr comes from, and it
can't be hard coded since it can change depending on the machine
compiling it.
Please bring up any further shortcomings this script may have with your
expectations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32261 Approved-By: Tom Tromey <tom@tromey.com>
Alan Modra [Tue, 21 Oct 2025 09:21:09 +0000 (19:51 +1030)]
Correct _bfd_elf_section_for_symbol
This function was added in commit 2f0c68f23bb3 as part of the compact
EH support. By the comments it looks like to code was copied from
bfd_elf_reloc_symbol_deleted_p without sufficient editing, and would
only work for local syms due to the discarded_section test left in
place for global syms. Fix that, and remove the discard param.
* elf-bfd.h (_bfd_elf_section_for_symbol): Update prototype.
* elf-eh-frame.c (_bfd_elf_parse_eh_frame_entry): Adjust.
* elflink.c (_bfd_elf_section_for_symbol): Remove "discard".
Don't test for discarded_section.
Tom Tromey [Sat, 18 Oct 2025 20:33:06 +0000 (14:33 -0600)]
Only set call site if not empty
In an earlier discussion, I noted that most compunit_symtabs do not
have a call-site hash table, so inlining the object into
compunit_symtab did not make sense.
It turns out that this is not entirely true -- while most
compunit_symtabs do not have any data in this object, the object
itself is always created. This in turn is a regression introduced by
commit de2b4ab5 ("Convert dwarf2_cu::call_site_htab to new hash
table").
This patch fixes the issue by arranging to only store a call-site hash
table when it is non-empty.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Simon Marchi [Sat, 11 Oct 2025 03:59:32 +0000 (23:59 -0400)]
gdb, gdbserver, gdbsupport: trim trailing whitespaces
I noticed my IDE (VSCode) starting to automatically trim trailing
whitespaces on save, despite the setting for it being disabled. I
realized that this is because the .editorconfig file now has
trim_trailing_whitespace = true
for many file types. If we have this EditorConfig setting forcing
editors to trim trailing whitespaces, I think it would make sense to
clean up trailing whitespaces from our files. Otherwise, people will
always get spurious whitespace changes when editing these files.
projects / thirdparty / binutils-gdb.git / log
