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.
Use the suffix "maybe_inline" to differentiate it from
find_symbol_for_pc_sect. find_symbol_for_pc_sect_maybe_inline can
return symbols for inline functions, while find_symbol_for_pc_sect
doesn't.
Change-Id: I6c4ef961383429ee26c8fcc0cc5df2e4e1e24959 Approved-by: Kevin Buettner <kevinb@redhat.com>
Simon Marchi [Wed, 8 Oct 2025 19:01:34 +0000 (15:01 -0400)]
gdb: fix slowdown during skeletonless type units processing
My commit 6474c699a525 ("gdb/dwarf: sort dwarf2_per_bfd::all_units by
(section, offset)") introduced a pretty bad performance regression in
the "skeletonless type units" step. I have a pretty big executable
(Blender) compiled with -gsplit-dwarf (to generate .dwo files) and
-fdebug-types-section (to generate type units). Before the offending
commit:
Time for "DWARF skeletonless type units": wall 29.126, user 28.507, sys 0.497, user+sys 29.004, 99.6 % CPU
... and after:
Time for "DWARF skeletonless type units": wall 120.768, user 119.543, sys 0.651, user+sys 120.194, 99.5 % CPU
The reason for the slowdown is that add_type_unit now inserts type units
at the right place in the all_units vector to keep it sorted. These
repeated insertions in the middle of the vector require shifting a lot
of elements and end up taking a lot of time.
This patch fixes it by doing just one sort at the end of
process_skeletonless_type_units. The responsibility of keeping the
all_units sorted is delegated to the callers of add_type_unit. The
other two callers call finalize_all_units right after calling
add_type_unit.
One drawback that is probably not a real one: in
process_skeletonless_type_unit, we call process_type_unit. If something
in there needs to look up another type unit by (section, offset), it
wouldn't find it. I don't think that's a real issue though, as type
units are typically self contained. If a type unit needs to refer to a
type defined in another type unit, it would do so by signature, with
DW_FORM_ref_sig8. And during the indexing phase, I don't think we even
look at the DW_AT_type of things anyway.
With this patch applied, I am back to:
Time for "DWARF skeletonless type units": wall 29.277, user 28.632, sys 0.521, user+sys 29.153, 99.6 % CPU
I would like to cherry pick this patch to GDB 17, to avoid shipping GDB
17 with the performance regression.
Change-Id: I2a5b89ebca9e1a4e6248032e144520c9a579f47a
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33526 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Kévin Le Gouguec [Mon, 20 Oct 2025 14:54:39 +0000 (16:54 +0200)]
Drop bashism from configure script
Results of evaluating 'test "no" == yes' in non-Bash shells range from
unfortunate (dash: "test: no: unexpected operator") to comically wrong
(AdaCore's gsh: returns 0).
Bruce McCulloch [Fri, 17 Oct 2025 13:00:25 +0000 (14:00 +0100)]
libctf: fix libctf/testsuite/libctf-lookup/multidim-array on older arches
This patch inverts the ordering of nelems on multidimensional arrays on
versions of gcc without the CTF_F_ARRNELEMS flag. This allows those
systems which run older gcc to pass the test without modification to the
multidim-array.lk file.
libctf/ChangeLog:
* testsuite/libctf-lookup/multidim-array.c: Test fixes.
Tom de Vries [Mon, 20 Oct 2025 09:58:32 +0000 (11:58 +0200)]
[gdb/testsuite] Fix gdb.tui/resize-3.exp on ppc64-linux
On ppc64-linux, with test-case gdb.tui/resize-3.exp I run into:
...
FAIL: gdb.tui/resize-3.exp: after resize: Assembler for foo is shown
...
because the disassembly window shows:
...
0 +----------------------------------------------------------------------+
1 | 0x10000093c <.foo> std r31,-8(r1) |
2 | 0x100000940 <.foo+4> stdu r1,-64(r1) |
3 | 0x100000944 <.foo+8> mr r31,r1 |
4 |B+>0x100000948 <.foo+12> li r9,0 |
...
and we grep for "<foo".
Tom de Vries [Mon, 20 Oct 2025 09:16:43 +0000 (11:16 +0200)]
[gdb/testsuite] Use with_cwd in gdb.src/pre-commit.exp
I ran the testsuite and ran into ERRORs in two test-cases,
gdb.trace/save-trace.exp and gdb.threads/tls-sepdebug.exp.
Recently added test-case gdb.src/pre-commit.exp changes the working directory,
and the change stays active in following test-cases, which was not the
intention.
Indu Bhagat [Mon, 20 Oct 2025 04:11:54 +0000 (21:11 -0700)]
libsframe: use const qualifier for sframe_header object
...where applicable.
For the static functions that do not modify the sframe_header object,
use const. Ditto for local vars.
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
libsframe/
* sframe.c (sframe_get_hdr_size): Use const qualifier.
(sframe_header_sanity_check_p): Likewise.
(flip_sframe): Use const for local var.
(sframe_decode): Likewise. While at it, use similar looking var
name.
(sframe_decoder_get_hdr_size): Use const for local var.
(sframe_decoder_get_abi_arch): Likewise.
(sframe_decoder_get_version): Likewise.
(sframe_decoder_get_fixed_fp_offset): Likewise.
(sframe_decoder_get_fixed_ra_offset): Likewise.
(sframe_get_funcdesc_with_addr_internal): Likewise.
(sframe_decoder_get_num_fidx): Likewise.
(sframe_encoder_get_hdr_size): Likewise.
(sframe_encoder_get_abi_arch): Likewise.
(sframe_encoder_get_version): Likewise.
(sframe_encoder_get_num_fidx): Likewise.
Tom de Vries [Fri, 17 Oct 2025 18:27:40 +0000 (20:27 +0200)]
[gdb/python] Use PyConfig for python 3.9
On ppc64le-linux (AlmaLinux 9.6) with python 3.9 and test-case
gdb.python/py-failed-init.exp I run into:
...
builtin_spawn $gdb -nw -nx -q -iex set height 0 -iex set width 0 \
-data-directory $build/gdb/data-directory -iex set interactive-mode on^M
Python path configuration:^M
PYTHONHOME = 'foo'^M
PYTHONPATH = (not set)^M
program name = '/usr/bin/python'^M
isolated = 0^M
environment = 1^M
user site = 1^M
import site = 1^M
sys._base_executable = '/usr/bin/python'^M
sys.base_prefix = 'foo'^M
sys.base_exec_prefix = 'foo'^M
sys.platlibdir = 'lib64'^M
sys.executable = '/usr/bin/python'^M
sys.prefix = 'foo'^M
sys.exec_prefix = 'foo'^M
sys.path = [^M
'foo/lib64/python39.zip',^M
'foo/lib64/python3.9',^M
'foo/lib64/python3.9/lib-dynload',^M
]^M
Fatal Python error: init_fs_encoding: failed to get the Python codec of the \
filesystem encoding^M
Python runtime state: core initialized^M
ModuleNotFoundError: No module named 'encodings'^M
^M
Current thread 0x00007fffabe18480 (most recent call first):^M
<no Python frame>^M
ERROR: (eof) GDB never initialized.
Couldn't send python print (1) to GDB.
UNRESOLVED: gdb.python/py-failed-init.exp: gdb-command<python print (1)>
Couldn't send quit to GDB.
UNRESOLVED: gdb.python/py-failed-init.exp: quit
...
The test-case expects gdb to present a prompt, but instead gdb calls exit
with this back trace:
...
(gdb) bt
#0 0x00007ffff6e4bfbc in exit () from /lib64/glibc-hwcaps/power10/libc.so.6
#1 0x00007ffff7873fc4 in fatal_error.lto_priv () from /lib64/libpython3.9.so.1.0
#2 0x00007ffff78aae60 in Py_ExitStatusException () from /lib64/libpython3.9.so.1.0
#3 0x00007ffff78c0e58 in Py_InitializeEx () from /lib64/libpython3.9.so.1.0
#4 0x0000000010b6cab4 in py_initialize_catch_abort () at gdb/python/python.c:2456
#5 0x0000000010b6cfac in py_initialize () at gdb/python/python.c:2540
#6 0x0000000010b6d104 in do_start_initialization () at gdb/python/python.c:2595
#7 0x0000000010b6eaac in gdbpy_initialize (extlang=0x11b7baf0 <extension_language_python>)
at gdb/python/python.c:2968
#8 0x000000001069d508 in ext_lang_initialization () at gdb/extension.c:319
#9 0x00000000108f9280 in captured_main_1 (context=0x7fffffffe870)
at gdb/main.c:1100
#10 0x00000000108fa3cc in captured_main (context=0x7fffffffe870)
at gdb/main.c:1372
#11 0x00000000108fa4d8 in gdb_main (args=0x7fffffffe870) at gdb/main.c:1401
#12 0x000000001001d1d8 in main (argc=3, argv=0x7fffffffece8) at gdb/gdb.c:38
...
This may be a python issue [1].
The problem doesn't happen if we use the PyConfig approach instead of the
py_initialize_catch_abort approach.
Fix this by using the PyConfig approach starting 3.9 (previously, starting
3.10 to avoid Py_SetProgramName deprecation in 3.11).
It's possible that we have the same problem and need the same fix for 3.8, but
I don't have a setup to check that. Add a todo in a comment.
Tested on ppc64le-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://github.com/python/cpython/issues/107827
gdb: remove program_space::core_bfd member function
These commits changed how the validate_files function (in corefile.c),
which is where the warning is emitted, find the core file BFD object.
Prior to the above commits, the core file BFD was stored in the
program_space, and was set by the time validate_files was called.
After the above commits the core file BFD is stored in the inferior's
core_target, and can only be accessed if the core_target has been
pushed onto the inferior's target stack.
Unfortunately, validate_files is called just before core_target is
pushed. As a result, in validate_files it appears as if there is no
core file loaded, and so no validation is performed.
This commit fixes that by moving the call to validate_files to after
the core_target is pushed. The warning is now restored.
I was surprised that this wasn't caught in testing. I was sure we had
a test for that warning. But, when I look now, I cannot find any such
test, so this commit adds one.
While I'm adding the test, validate_files also has a warning that it
can emit if the core file is older than the executable. I've made
sure that the test covers this warning too.
Jeremy Bryant [Tue, 14 Oct 2025 21:55:39 +0000 (22:55 +0100)]
doc/python.texi : Adapt to Python 3 print syntax
This change adapts the print syntax to Python 3.
The documentation examples will then work on current installations.
Python 2 was sunsetted in January 2020.
Tom de Vries [Fri, 17 Oct 2025 06:02:02 +0000 (08:02 +0200)]
[gdb/tdep] Fix inferior call return of small char array for ppc64 v1 abi some more
PR tdep/33534 reports a regression due to commit 13f1820106c ("[gdb/tdep] Fix
inferior call return of small char array for ppc64 v1 abi").
The regression can be reproduced with the test-case introduced in the commit:
gdb.ada/return-small-char-array.exp, on a ppc64-linux setup with v1 elf abi
(cfarm121).
The commit contains two changes to a piece of code in
ppc64_sysv_abi_return_value:
...
/* Small character arrays are returned, right justified, in r3. */
- if (valtype->code () == TYPE_CODE_ARRAY
+ if (tdep->elf_abi == POWERPC_ELF_V1
+ && valtype->code () == TYPE_CODE_ARRAY
&& !valtype->is_vector ()
&& valtype->length () <= 8
- && valtype->target_type ()->code () == TYPE_CODE_INT
+ && (valtype->target_type ()->code () == TYPE_CODE_INT
+ || valtype->target_type ()->code () == TYPE_CODE_CHAR)
&& valtype->target_type ()->length () == 1)
...
The first change limits the effect of the if clause to the v1 elf abi. This
change doesn't affect the regression, since it's on a ppc64-linux setup with
v1 elf abi. Furthermore, it's correct in the sense that the v2 elf abi
doesn't have this kind of special treatment of small character arrays.
The second change is the part that causes the regression. The code itself
seems correct, in the sense that it enables gdb to recognize small char arrays
in ada.
The regression stems from the following discrepancy.
The comment in gdb states that "small character arrays are returned, right
justified, in r3". This matches the v1 ABI [1].
OTOH, gcc produces code that is not in agreement with this. Instead, it
passes the small character arrays in memory, in a caller-allocated storage
buffer pointed at by r3. This turns out to be an gcc bug [2].
Fix this by treating this as an abi spec bug, and replacing the code handling
the "Small character arrays" case with a comment.
Doing so reveals that there are two problems in the test-case:
- missing fvar-tracking, and
- the "step 2" command doesn't land at the intended line.
Fix these by:
- adding fvar-tracking, and
- setting a breakpoint at the intended line, and continuing to it.
Tested on ppc64-linux (v1 abi), ppc64le-linux (v2 abi), and x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33534
Alan Modra [Fri, 17 Oct 2025 00:34:40 +0000 (11:04 +1030)]
Don't build libctf tests in source dir
Running the libctf testsuite currently leaves big-struct-ctf.o in
libctf/testsuite/libctf-lookup/.
It ought to be possible to make the binutils source dir read-only,
and putting compiler output in the source dir leads to interesting
effects when testing multiple binutils targets in parallel.
* lib/ctf-lib.exp (run_lookup_test): For "link: objects" compile
objects in tmpdir.
Indu Bhagat [Thu, 16 Oct 2025 18:20:21 +0000 (11:20 -0700)]
libsframe: fix warning about argument of sframe_fre_sanity_check_p
Recent commit (6ca8915c) added a new API sframe_fre_get_ra_undefined_p
(). It has a 'const sframe_frame_row_entry *fre' argument, causing a
warning in function ‘sframe_fre_get_ra_undefined_p’:
libsframe/sframe.c:794:50: warning: passing argument 1 of
‘sframe_fre_sanity_check_p’ discards ‘const’ qualifier from pointer
target type [-Wdiscarded-qualifiers]
794 | if (fre == NULL || !sframe_fre_sanity_check_p (fre))
| ^~~
libsframe/sframe.c:293:52: note: expected ‘sframe_frame_row_entry *’ but
argument is of type ‘const sframe_frame_row_entry *’
293 | sframe_fre_sanity_check_p (sframe_frame_row_entry *frep)
| ~~~~~~~~~~~~~~~~~~~~~~~~^~~~
Fix it by using const qualifier.
libsframe/
* sframe.c (sframe_fre_sanity_check_p): Use const.
Tom de Vries [Thu, 16 Oct 2025 10:09:57 +0000 (12:09 +0200)]
[pre-commit] Add check-gnu-style
I got a review comment [1] because I forgot to do "space before paren".
I realized I forgot to run check_GNU_style.py, a script from the GCC repo,
which warns about things like this.
[ The python script has been around since 2017 (and an earlier version written
in shell script since 2010). ]
So for this change in gdb/gdb.c:
...
- return gdb_main (&args);
+ return gdb_main(&args);
...
we get:
...
$ ./contrib/check_GNU_style.py <(git diff)
=== ERROR type #1: there should be exactly one space between function name \
and parenthesis (1 error(s)) ===
gdb/gdb.c:38:17: return gdb_main(&args);
...
Add a pre-commit hook to do this automatically.
This copies two files from the GCC repo to root-level contrib, and adds a
wrapper script gdb/contrib/check-gnu-style-pre-commit.sh (checked with
shellcheck).
The wrapper script is setup to not fail on violations, so the messages are
informational at this point. I'm not sure all checks are 100% applicable to
our coding style.
The python script check_GNU_style.py has two dependencies: unidiff and
termcolor, which users need to install themselves.
The check is added at the pre-commit stage. I also considered post-commit,
and I'm still not sure what is the better choice.
As with all pre-commit checks, if the check is not to your liking, you can
use SKIP=check-gnu-style to skip it.
In summary, with the new pre-commit check we get:
...
$ git commit -a -m "style error"
black...............................................(no files to check)Skipped
flake8..............................................(no files to check)Skipped
isort...............................................(no files to check)Skipped
codespell...........................................(no files to check)Skipped
check-include-guards................................(no files to check)Skipped
check-gnu-style.........................................................Passed
- hook id: check-gnu-style
- duration: 0.04s
=== ERROR type #1: there should be exactly one space between function name \
and parenthesis (1 error(s)) ===
gdb/gdb.c:38:17: return gdb_main(&args);
tclint..............................................(no files to check)Skipped
black...............................................(no files to check)Skipped
flake8..............................................(no files to check)Skipped
codespell...........................................(no files to check)Skipped
check-include-guards................................(no files to check)Skipped
codespell-log...........................................................Passed
- hook id: codespell-log
- duration: 0.19s
tclint...............................................(no files to check)Skipped
[master $hex] style error
...
Approved-By: Simon Marchi <simon.marchi@efficios.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-September/220983.html
Tom de Vries [Thu, 16 Oct 2025 09:38:53 +0000 (11:38 +0200)]
[gdb/c++] Fix hang on whatis std::string::npos
Consider the following scenario, exercising "whatis std::string::npos":
...
$ cat test.cc
int main (void) {
std::string foo = "bar";
return foo.size ();
}
$ g++ test.cc -g
$ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in
+start
Temporary breakpoint 1 at 0x4021c7: file test.cc, line 3.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Temporary breakpoint 1, main () at test.cc:3
3 std::string foo = "bar";
+info auto-load python-scripts
No auto-load scripts.
+whatis std::string
type = std::__cxx11::basic_string<char, std::char_traits<char>, \
std::allocator<char> >
+whatis std::string::npos
type = const std::__cxx11::basic_string<char, std::char_traits<char>, \
std::allocator<char> >::size_type
...
After installing the package containing the pretty-printers:
...
$ zypper install libstdc++6-pp
...
and adding some commands to use them, we get instead:
...
$ gdb -q -batch -iex "set trace-commands on" a.out -x gdb.in
+add-auto-load-safe-path /usr/share/gdb/auto-load
+add-auto-load-scripts-directory /usr/share/gdb/auto-load
+start
...
+info auto-load python-scripts
Loaded Script
Yes /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.34-gdb.py
+whatis std::string
type = std::string
+whatis std::string::npos
type = const std::__cxx11::basic_string<char, std::char_traits<char>, \
std::allocator<char> >::size_type
...
Note that "whatis std::string" now prints "std::string", but that
"whatis std::string::npos" still uses the longer name for std::string.
This is when compiling gdb with -O0. With -O2 -fstack-protector-strong, we
have a hang instead:
...
+whatis std::string
type = std::string
+whatis std::string::npos
<HANG>
...
Valgrind complains about an uninitialized field
demangle_component::d_counting, which is fixed by using
cplus_demangle_fill_name in replace_typedefs_qualified_name.
After fixing that, the hang is also reproducible at -O0.
The hang happens because we're stuck in the while loop in
replace_typedefs_qualified_name, replacing "std::string::size_type" with
"std::string::size_type".
Fix this in inspect_type by checking for this situation, getting us instead:
...
+whatis std::string
type = std::string
+whatis std::string::npos
type = const std::string::size_type
$
...
The test-case is a bit unusual:
- pretty-print.cc is a preprocessed c++ source, reduced using cvise [1], then
hand-edited to fix warnings with gcc and clang.
- the pretty-printer .py file is a reduced version of
/usr/share/gcc-15/python/libstdcxx/v6/printers.py.
Using the test-case (and the cplus_demangle_fill_name fix), I managed to
reproduce the hang on both:
- openSUSE Leap 15.6 with gcc 7, and
- openSUSE Tumbleweed with gcc 15.
The test-case compiles with clang, but the hang didn't reproduce.
Jens Remus [Thu, 16 Oct 2025 09:09:06 +0000 (11:09 +0200)]
s390: Do not rewrite insns and their relocs in linker if --no-relax
Under certain conditions the linker rewrites:
- GOT access using lgrl to larl, changing the GOTENT to a PC32DBL reloc
- GOT access using lg to larl, changing the GOT20 to a PC32DBL reloc
- Relative long addressing instructions of weak symbols, which
definitively resolve to zero to either (1) load address of zero,
(2) a NOP, or (3) a trapping instruction, changing the relocation to
a NONE reloc.
Suppress rewriting of non-TLS instructions and related relocations in
linker if option --no-relax is specified. This aligns with LLVM linker
behavior on s390.
Like x86-64 do not actually enable the linker relaxation option by
default, as other targets would do using ENABLE_RELAXATION or
TARGET_ENABLE_RELAXATION in their linker emulation scripts. Instead
perform linker instruction/relocation rewrites by default unless linker
option --no-relax is explicitly specified by the user. This ensures no
functional change unless --no-relax is used.
bfd/
* elf64-s390.c (elf_s390_relocate_section): Do not rewrite
non-TLS instructions and related relocations if --no-relax.
* elf32-s390.c (elf_s390_relocate_section): Likewise.
ld/testsuite/
* ld-s390/s390.exp: New tests. Same as gotreloc_*-1a and
weakundef-*a, but with linker option --no-relax, to verify
suppression of linker non-TLS insn and reloc rewrites.
* ld-s390/gotreloc_31-1b.dd: Likewise.
* ld-s390/gotreloc_31-no-pie-1b.dd: Likewise.
* ld-s390/gotreloc_64-no-pie-1b.dd: Likewise.
* ld-s390/gotreloc_64-norelro-1b.dd: Likewise.
* ld-s390/gotreloc_64-relro-1b.dd: Likewise.
* ld-s390/weakundef-1b.d: Likewise. Check for expected reloc
overflows.
* ld-s390/weakundef-2b.d: Likewise.
Jens Remus [Thu, 16 Oct 2025 09:06:17 +0000 (11:06 +0200)]
s390: Rewrite emitted relocations when rewriting instructions
When the linker rewrites instructions it may need to rewrite the
associated relocations, so that when emitted with option --emit-relocs,
they make sense with the rewritten instructions. Otherwise post link
analysis and optimization tools may not be able to perform correct
modifications of executables.
Under certain conditions the linker rewrites:
- GOT access using lgrl to larl, changing the GOTENT to a PC32DBL reloc
- GOT access using lg to larl, changing the GOT20 to a PC32DBL reloc
- Relative long addressing instructions of weak symbols, which
definitively resolve to zero, to either (1) load address of zero,
(2) a NOP, or (3) a trapping instruction.
In case of a rewrite of GOT access using lgrl/lg to larl emit the
PC32DBL relocation. In case of a rewrite of relative long addressing
instructions of weak symbols, which definitively resolve to zero, emit
a NONE relocation and reset the symbol table index and addend. Update
the gotreloc* and weakundef* tests to check for the respective
relocations.
This aligns with how GNU linker behaves on x86-64, when rewriting
instructions/relocations in elf_x86_64_convert_load_reloc().
Andrew Burgess [Mon, 13 Oct 2025 13:44:56 +0000 (14:44 +0100)]
gdb/testsuite: remove incorrect global variable accesses
I noticed in gdb.replay/missing-thread.exp a reference to $testfile in
a location where 'testfile' had not been made available via a use of
'global'. The uses looked like this:
I think there are three problems here, the $testfile is invalid
because there's no 'global testfile' making the variable available.
The use of $testfile is redundant anyway as 'unsupported' already adds
the script name to the output line. The final text within parenthesis
is bad style that's an important part of the output, but GDB test name
style is that text in parenthesis is additional text that could be
ignored, e.g. "(timeout)".
Replace the above with just:
unsupported "couldn't start gdbreplay"
This same construct has been copied into multiple gdb.replay/ tests,
so fix them all.
There's no change to what is actually tested after this commit.
hppa64: Fix addition of symbols to local dynamic table
This fixes lookup failure in elf64_hppa_finalize_dynreloc.
2025-10-15 John David Anglin <danglin@gcc.gnu.org>
bfd/ChangeLog:
* elf64-hppa.c (elf64_hppa_check_relocs): Record local
dynamic symbol if a dynamic relocation is needed.
(allocate_global_data_dlt) Fix typo.
(allocate_dynrel_entries): Don't record symbol.
(elf64_hppa_finalize_dynreloc): Assert dynindx is not -1.
Jens Remus [Wed, 15 Oct 2025 15:45:48 +0000 (17:45 +0200)]
gas: sframe: Represent .cfi_undefined RA as FRE without offsets
In DWARF CFI an "undefined" register rule for the return address (RA)
register indicates that there is no return address and the stack trace
is complete.
Represent DW_CFA_undefined as SFrame FRE without any offsets, so that a
stack tracer implementation can use this as indication that an outermost
frame has been reached and the stack trace is complete.
This representation is backward compatible, as existing stack tracers
should already deal with the case, that an SFrame FRE a so far invalid
offset count of zero and stop the trace.
include/
* sframe.h (SFRAME_V2_FRE_RA_UNDEFINED_P): New macro to test
FRE info word for RA undefined (FRE without any offsets).
binutils/
* NEWS: Mention SFrame can represent an undefined RA as FRE
without any offsets.
gas/
* gen-sframe.h (struct sframe_row_entry): Add ra_undefined_p
flag.
* gen-sframe.c (sframe_row_entry_new): Initialize ra_undefined_p
flag to not set.
(sframe_row_entry_initialize): Treat ra_undefined_p flag as
sticky.
(sframe_fre_set_ra_track): Reset ra_undefined_p flag.
(sframe_xlate_do_restore): Reset ra_undefined_p flag to saved
state.
(sframe_xlate_do_same_value): Reset ra_undefined_p flag.
(sframe_xlate_do_cfi_undefined): For RA set ra_undefined_p flag.
(output_sframe_row_entry): Represent RA undefined as SFrame FRE
without any offsets and FRE info word fields zeroed.
* NEWS: Mention assembler represents .cfi_undefined RA in SFrame
as FRE without any offsets.
libsframe/
* doc/sframe-spec.texi (Changes from Version 1 to Version 2):
Mention that a SFrame FRE without any offsets flag indicates an
outermost frame with an undefined RA.
(fre_offset_count): Document that a FRE offset count of zero
indicates an outermost frame with an undefined RA.
* sframe.c (sframe_get_fre_ra_undefined_p): Use macro
SFRAME_V2_FRE_RA_UNDEFINED_P.
(sframe_fre_get_fp_offset, sframe_fre_get_ra_offset): Do not
return fixed FP/RA offset if RA undefined.
* sframe-dump.c (dump_sframe_func_with_fres): Show FRE without
any offsets as "RA undefined".
gas/testsuite/
* gas/cfi-sframe/cfi-sframe.exp: Run tests for .cfi_undefined RA
on AArch64, s390x, and x86-64.
* gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.d: Add test
for .cfi_undefined RA on AArch64.
* gas/cfi-sframe/cfi-sframe-aarch64-ra-undefined-1.s: Likewise.
* as/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.d: Add test
for .cfi_undefined RA on s390x.
* gas/cfi-sframe/cfi-sframe-s390x-ra-undefined-1.s: Likewise.
* gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.d: Add test
for .cfi_undefined RA on x86-64.
* gas/cfi-sframe/cfi-sframe-x86_64-ra-undefined-1.s: Likewise.
Jens Remus [Wed, 15 Oct 2025 15:45:48 +0000 (17:45 +0200)]
include: libsframe: Add API to get RA undefined
SFrame FREs without any offsets will later be used to represent an
undefined return address (RA) in SFrame. This API can then be used,
for instance by libsframe when dumping SFrame stack trace information
(e.g. in objdump and readelf), to test for RA undefined. Other users
of libsframe need the same capability.
include/
* sframe-api.h (sframe_fre_get_ra_undefined_p): New declaration.
libsframe/
* libsframe.ver (sframe_fre_get_ra_undefined_p): List new API.
* sframe.c (sframe_fre_get_ra_undefined_p): New definition.
Jens Remus [Wed, 15 Oct 2025 15:45:48 +0000 (17:45 +0200)]
libsframe: s390: No further decode if sframe_get_fre_offset returns err
SFrame FREs without any offsets will later be used to represent
.cfi_undefined RA in SFrame.
As a result the API to get the CFA offset can return an error value, if
there are no offsets. Do not apply the s390x-specific decoding of CFA
offset on the error return value.
libsframe/
* sframe.c (sframe_fre_get_cfa_offset): Do not apply s390x-
specific decoding to error return value.
Jens Remus [Wed, 15 Oct 2025 15:45:48 +0000 (17:45 +0200)]
gas: ld: libsframe: Support for SFrame FDEs without any FREs
Allow SFrame sections without any FREs, that can occur if they solely
contain FDEs without any FREs. For FDEs without and FREs set the
offset to the first FRE to zero.
libsframe/
* sframe.c (sframe_encoder_write_sframe): Allow SFrame sections
without any FREs. For FDEs without any FREs set the offset to
the first FRE to zero.
gas/
* gen-sframe.c (output_sframe_funcdesc): For FDEs without any
FREs set the offset to the first FRE to zero.
Today, GDB links against the Python library using the unstable API. This
approach causes portability issues of the generated GDB artifact. Indeed
the built artifact is tighly coupled with the specific version of Python
that it was compiled with. Using a slighly minor version of Python can
cause unpredictable crashes at runtime due to ABI instability between
the Python versions, even minor ones.
The solution would consist in restricting the usage of Python functions
to the limited C API controlled via Py_LIMITED_API that must be defined
before the inclusion of <Python.h>.
This patch does not aim at porting the whole GDB codebase to the Python
limited C API, but rather enabling a development mode where developers
can experiment with the Python limited C API, and fix issues.
This development mode is accessible with the configure option
--enable-py-limited-api which is set by default to 'no'.
Note: the version of the Python limited API is currently set to 3.11
because of PyBuffer_FillInfo and PyBuffer_Release. This choice is not
frozen, and could be reviewed later on depending on newly discovered
issues during the migration.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Matthieu Longo [Wed, 16 Jul 2025 16:17:36 +0000 (17:17 +0100)]
gdb: make Python conftest compatible with Python limited C API
The current test to check the support of '--dynamic-list' linker flag
uses PyRun_SimpleString (), which is part of the unstable API. As it is
now, the test will systematically fail due to the undefined symbol
rather than testing the import of ctypes.
This patch replaces PyRun_SimpleString () by an equivalent code relying
on the limited C API, and compatible with Python 3.4.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23830 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 11 Oct 2025 04:08:49 +0000 (00:08 -0400)]
gdb/linespec: take some parameters by reference
Change the `sal` parameter of add_sal_to_sals to be a reference. This
will make things a bit cleaner in a following patch (and it would be a
good change on its own anyway).
Change the `sals` parameter to a reference as well, while at it, which
trickles up to minsym_found.
Change-Id: I348414308940c14fa6030bc41c52f507aa6d1c12 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Sat, 11 Oct 2025 04:06:20 +0000 (00:06 -0400)]
gdb: remove unnecessary use of symtab_and_line in create_sals_line_offset
create_sals_line_offset uses a symtab_and_line essentially just to hold
a line number and pass it down to decode_digits_list_mode. Change the
local variable to be an int, and change decode_digits_list_mode to
accept an int, instead of a symtab_and_line. I think this makes the
code a bit simpler.
Change-Id: I445d2473f042693c3a4f2693877408f85100cd1f Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Mon, 22 Sep 2025 15:08:46 +0000 (09:08 -0600)]
Fix use of "main" marker in gdb index
Tom de Vries noticed that with .gdb_index, the "main" marker would
sometimes seemingly be ignored.
I tracked this down to an interaction between the rewritten reader and
the "main"-finding code in cooked_index. With the ordinary DWARF
scanner, a C "main" won't be marked as IS_MAIN; whereas with
.gdb_index this can happen. In this case, the code thinks that C
requires canonicalization (which is only true for types), and skips
using the symbol.
This patch fixes the problem and adds some comments explaining what is
going on.
projects / thirdparty / binutils-gdb.git / log
