Alan Modra [Sun, 19 Jul 2026 08:12:39 +0000 (17:42 +0930)]
init-mixed.c count
The variable isn't a counter so rename it, and use small values that
won't overflow a target with 16-bit int. Since commit 2e806738bd
there is a possibility of running tests on such targets.
* testsuite/ld-elf/init-mixed.c: Rename "count" to "order"
and use values of 0 to 6 when checking init/fini order.
Jan Dubiec [Sat, 18 Jul 2026 07:52:54 +0000 (09:52 +0200)]
ld: testsuite: Associate C identifiers with symbols
Some targets prepend an underscore to C identifier, while others do
not (e.g. H8 vs. ARM). This can cause problems in two situations:
1. when linking C and assembly code;
2. when a symbol name is specified on the linker's command line.
This patch resolves both issues by using the asm keyword to associate C
identifiers with the corresponding assembler/linker symbol names in a
target-independent manner.
Alan Modra [Sun, 19 Jul 2026 05:19:21 +0000 (14:49 +0930)]
convert dos eol to unix
A number of testsuite files have dos CR/LF end of line. Fix most of
them, so that we are less likely to run into patch failures when
contributors provide patches to these files, such as:
Hunk #1 FAILED at 1 (different line endings).
My version of git, 2.51.0, does not tell you the reason whe running
"git am", just "patch does not apply".
gprofng/examples/mxv-pthreads/README.md is also converted to unix.
Andrew Burgess [Thu, 25 Jun 2026 14:58:50 +0000 (14:58 +0000)]
gdb: recreate the frame_info_ptr in get_prev_frame_maybe_check_cycle
Currently frame_info_ptr caches the frame_id at construction time, see
frame_info_ptr::frame_info_ptr in frame.c. The problem with this is
that a frame's frame-id might not be known at this point.
The function get_prev_frame_maybe_check_cycle calls get_prev_frame_raw
to create the previous frame, placing the result into a frame_info_ptr
PREV_FRAME. For frames other than frame 0, compute_frame_id is then
called computing the frame-id. However, the call to compute_frame_id
only updates the frame_info object itself, the frame_info_ptr
PREV_FRAME is not updated with the new frame-id.
What this means is that in get_prev_frame_maybe_check_cycle, the
PREV_FRAME local has no cached frame-id.
What we see is that the frame_info_ptr created in
get_prev_frame_maybe_check_cycle, which lacks a cached frame_id, can
be passed all the way back to lookup_selected_frame, where it will be
stored in the SELECTED_FRAME global by a call to select_frame. The
outer get_selected_frame call (in the above backtrace) will then
return the SELECTED_FRAME global, which lacks a cached frame-id.
If GDB ever tries to reinflate the SELECTED_FRAME frame_info_ptr (or a
copy of it), then we will trigger the assert:
`gdb_assert (frame_id_p (m_cached_id));` which can be found in
`frame_info_ptr::reinflate` in frame.c.
An example of how this can be triggered is included in the updated
test case:
- The 'up' command sets the selected frame to a frame with
level > 0.
- An inferior call invalidates the selected frame.
- The selected frame is rebuilt following the call-stack above.
The wrapping frame_info_ptr object doesn't cache the frame-id.
- The 'frame' command invokes another inferior call for the pretty
printer, which flushes the frame cache.
- The frame_info_ptr is reinflated, e.g., to print the next
argument, and this hits the assertion mentioned above.
There are only 3 places in GDB where new frame_info objects are
created: create_sentinel_frame, create_new_frame, and
get_prev_frame_raw. Of these, the first two always calculate the
frame_id before placing the frame_info object into a frame_info_ptr.
Only get_prev_frame_raw, which is only called from
get_prev_frame_maybe_check_cycle, creates the frame_info_ptr before
the frame_id is calculated.
There are two places where PREV_FRAME is returned from
get_prev_frame_maybe_check_cycle. The first is only for frame #0.
The frame_info_ptr::reinflate method doesn't need a frame_id for
frame #0, so the first return is not a problem.
The second return from get_prev_frame_maybe_check_cycle is done after
the frame_id has been calculated, and it is here that the problem can
be fixed. If we create a new frame_info_ptr to replace PREV_FRAME
then this new frame_info_ptr will have a cached frame_id and the
problem described above will no longer occur.
Co-Authored-By: Rohr, Stephan <stephan.rohr@intel.com>
Hui Li [Mon, 13 Jul 2026 10:37:24 +0000 (18:37 +0800)]
gdb: LoongArch: Add internal TLS support
Implements the LoongArch-specific get_tls_dtv_addr() and uses
svr4_tls_register_tls_methods() to register it, together with
svr4_tls_get_thread_local_address as the get_thread_local_address
gdbarch method, to support internal TLS address lookup.
LoongArch doesn't need get_tls_dtp_offset since musl's DTP_OFFSET
is defined as 0.
This is the LoongArch version of commit c34309bea22
("Internal TLS support for aarch64, x86_64, riscv, ppc64, and s390x").
Depends-On: bfc3ac0d13b
("LoongArch: Support R_LARCH_TLS_DTPREL32/64 used in debug section")
Before:
make check-gdb TESTS="gdb.base/tls-nothreads.exp"
=== gdb Summary ===
# of expected passes 101
# of known failures 48
make check-gdb TESTS="gdb.base/tls-dlobj.exp"
=== gdb Summary ===
# of expected passes 261
After:
make check-gdb TESTS="gdb.base/tls-nothreads.exp"
=== gdb Summary ===
# of expected passes 302
make check-gdb TESTS="gdb.base/tls-dlobj.exp"
=== gdb Summary ===
# of expected passes 523
Signed-off-by: Hui Li <lihui@loongson.cn> Approved-By: Simon Marchi <simon.marchi@efficios.com> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom de Vries [Sat, 18 Jul 2026 08:16:57 +0000 (10:16 +0200)]
[pre-commit] Set stages for isort
I noticed that isort runs for the manual stage:
...
$ pre-commit run --hook-stage manual
isort...............................................(no files to check)Skipped
...
That happens because unlike any other repo we're currently using, isort's
.pre-commit-hooks.yaml sets stages:
...
stages: [pre-commit, pre-merge-commit, pre-push, manual]
...
overriding the default setting in our .pre-commit-config.yaml:
...
default_stages: [pre-commit]
...
Fix this by adding a stages setting to the isort hook.
Ijaz, Abdul B [Fri, 15 Sep 2023 13:18:07 +0000 (15:18 +0200)]
gdb: add shadowed field in '-stack-list-locals/variables' mi commands
For C/C++/Fortran languages GDB prints same name variable multiple times in
case of variable shadowing and it is confusing for user to identify which
variable belongs to the current scope. So GDB now prints location information
for shadowed variables and add 'shadowed' field also in '-stack-list-locals'
and '-stack-list-variables' mi commands for super-block shadowed variable.
Suppose we have test.c file
1:int x = 3;
2: {
3: int x = 4;
4: int y = 5;
5: x = 99; /* break here */
6: }
The "-stack-list-locals" and "-stack-list-variables" mi commands at the
"break here" line gives the following output:
Ijaz, Abdul B [Fri, 15 Sep 2023 13:12:10 +0000 (15:12 +0200)]
gdb: add annotation in 'info locals' command for variables shadowing case
For C/C++/Fortran/Ada languages GDB prints same name variable multiple
times in case of variable shadowing and it is confusing for user to identify
which variable belongs to the current scope. So for such cases add location
info to the innermost listed variables and for super block variables add
"shadowed" annotation in the form of "<file.c:line, shadowed>".
Suppose we have
1:int x = 3;
2: {
3: int x = 4;
4: int y = 52;
5: x = 99; /* break here */
6: }
Currently:
(gdb) info locals
x = 4
y = 52
x = 3
After applying this patch, we obtain:
(gdb) info locals
x = 4 <file.c:3>
y = 52
x = 3 <file.c:1, shadowed>
The patch adds the location annotations by keeping track of inner block
and already printed variables to identify shadowing. So, GDB now prints
"<file.c:line, shadowed>" for shadowed super-block variables and
"<file.c:line>" for innermost declarations of such variables only.
The location annotations are printed for shadowed variables in case of
C/C++/Fortran/Ada languages. In Rust, it is possible to declare a
variable with the same name many times. So in this case, just the first
instance of the variable is printed. RUST language test "var_reuse.exp"
fails with rustc compiler version >= 1.73 so XFAIL is added accordingly.
Fix regex expression in the gdb.opt/inline-locals.exp test according to
this change. The test update is only required due to the existing gdb
known ticket gdb/25695 where this issue is seen with 7.5.0 version on
sles15sp6 but it is not seen anymore on the newer gcc versions e.g.
gcc-11.4.0.
The symtab()/filename() nullptr check was added specifically to avoid
the crash seen in gdb.dwarf2/missing-type-name-for-templates.exp where
template symbols may have no associated source file.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org> Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Tom Tromey [Wed, 1 Jul 2026 16:05:24 +0000 (10:05 -0600)]
Assume an unrecognized gnatmake is very new
I don't know why -- though I suspect there may have been a change to
the output of "gnatmake --version" -- but recently some gdb.ada tests
have stopped running when llvm-gnatmake is used.
The llvm-gnatmake I am testing against prints a version string that
isn't recognized by gnat_version_compare. However, it seems to me
that AdaCore is probably the main place where this can even occur; and
furthermore that without some extra work, it seems reasonable for
gnat_version_compare to assume that an unrecognized gnatmake is "very
new".
Tom Tromey [Tue, 30 Jun 2026 16:09:48 +0000 (10:09 -0600)]
Handle missing array descriptor in ada_type_of_array
The test case gdb.ada/mi_var_access.exp was failing with gnat-llvm.
Debugging this, I found that the problem was that with gnat-llvm, the
array descriptor would have a NULL pointer for the bounds when the
array was invalidated. That is, examining the object in C mode:
This was causing ada_type_of_array to return nullptr; with that
bubbling up to varobj and then MI as a "wrong" type in the MI output.
It seems to me that a null P_BOUNDS is reasonable; and that this case
can be handled in ada_type_of_array by examining the type of P_BOUNDS
without needing the bounds themselves.
The bound values are both set to 0 in this case, because
experimentally this is what is done at runtime in the GNAT-generated
code. Perhaps an explicitly empty array (1/0) would be better; I am
not certain.
Tom de Vries [Fri, 17 Jul 2026 14:30:15 +0000 (16:30 +0200)]
[gdb] Fix hard-coded constants in buildsym_compunit::make_blockvector
I came across some code in buildsym_compunit::make_blockvector that uses
hardcoded constants 0 and 1:
...
gdb_assert (blockvector->block (0)->is_global_block ());
gdb_assert (blockvector->block (1)->is_static_block ());
...
Fix this by instead using the symbolic constants GLOBAL_BLOCK and
STATIC_BLOCK.
The same function has an odd-looking for loop that uses a hard-coded '1' to
skip the global block:
...
/* The 'J > 1' here is so that we don't place the global block into
the map. For CU with gaps, the static block will reflect the
gaps, while the global block will just reflect the full extent of
the range. */
for (int j = num_blocks; j > 1; )
{
--j;
struct block *b = blockvector->block (j);
...
Fix this by rewriting it into an ordinary descending for loop, and using
symbolic constant GLOBAL_BLOCK to avoid the global block:
...
for (int j = num_blocks - 1; j > GLOBAL_BLOCK; --j)
{
struct block *b = blockvector->block (j);
...
PE/COFF stores symbol section numbers in a 16-bit field. Binutils used
signed 16-bit handling there, which limited normal PE objects to 32767
sections even though MSVC and Clang already accept a larger unsigned
range.
Raise the normal PE section limit to 65279, while keeping the PE/COFF
special section-number values for undefined, absolute and debug symbols
working correctly. Do this by decoding and encoding normal PE symbol
section numbers as unsigned values in the ordinary range, but preserving
the reserved PE constants explicitly.
Also add a gas test that exercises a normal PE object above the old
32767-section limit and checks that objdump reports the high section
number correctly.
bfd/ChangeLog:
* coffcode.h (COFF_DEFAULT_MAX_NSCNS): Define.
(bfd_coff_std_swap_table): Use it for the default maximum section
count.
(ticoff0_swap_table): Likewise.
(ticoff1_swap_table): Likewise.
* peXXigen.c (pe_decode_sym_section_number): New function.
(pe_encode_sym_section_number): New function.
(_bfd_XXi_swap_sym_in): Use pe_decode_sym_section_number.
(_bfd_XXi_swap_sym_out): Use pe_encode_sym_section_number.
Tom de Vries [Fri, 17 Jul 2026 11:18:28 +0000 (13:18 +0200)]
[pre-commit] Fix codespell-log hook
A recent commit added this top-level setting to .pre-commit-config.yaml:
...
files: '^(gdb|gdbserver|gdbsupport)/'
...
This broke the codespell-log hook, which is a commit-msg hook, which is called
with the commit message as first argument, typically .git/COMMIT_EDITMSG.
However, the top-level files setting filters out .git/COMMIT_EDITMSG, with the
consequence that the commit-msg hook is no longer called.
It seems obvious to me that this is a pre-commit bug: the files field is there
to filter files in the repository, which .git/COMMIT_EDITMSG is not one of.
But upstream disagrees [1].
The fix suggested upstream is to include .git/COMMIT_EDITMSG in the default
files setting.
That indeed works for a regular commit, but not for something like this:
...
$ tmp=$(mktemp)
$ echo 'msg' > $tmp
$ pre-commit run --hook-stage commit-msg --commit-msg-filename $tmp
...
which is roughly what we're using in the regression test.
We can't use .git/COMMIT_EDITMSG in the regression test, because the user may
be editing it, or using it in some other way.
We also cannot use say gdb/testsuite/gdb.src/commit-msg.txt, because using
that filename doesn't detect the regression.
Jan Beulich [Fri, 17 Jul 2026 07:23:35 +0000 (09:23 +0200)]
gas: don't recognize '8' and '9' as octal escape chars in strings
It's not clear why these were covered; it has been like this from the very
beginning of (available) source history. Yet more oddly, an old ia64
testcase actually uses such malformed escape sequences (which are being
adjusted).
Jan Beulich [Fri, 17 Jul 2026 07:23:07 +0000 (09:23 +0200)]
gas: ignore ONLY_STANDARD_ESCAPES in scrubber
The handling there is broken in several ways:
- It gets in the way of macro parameter names starting with one of the not
special cased values.
- For perhaps a small set of targets (SINGLE_QUOTE_STRINGS, M68k MRI
mode): While the "quotechar" static variable allows for string quotation
by other than '"', the case labels circumventing the warning only (and
potentially wrongly) cover '"'.
read.c:next_char_of_string() having similar checking in place, drop the
special casing (as as_warn() invocation) from here.
While adjusting macros/macros.exp XFAIL-ary for an affected testcase,
correct the referenced manifest symbol at the same time.
Jan Beulich [Fri, 17 Jul 2026 07:22:09 +0000 (09:22 +0200)]
x86: avoid duplication of testcase expectations in ilp32/
Besides needlessly consuming space (it's not that much, but still), the
unnecessary duplication also means the need to edit things in two places
when changes are being made.
Jan Beulich [Fri, 17 Jul 2026 07:21:48 +0000 (09:21 +0200)]
x86: accept LOCK on control register accesses only with ModR/M.reg == 0
Reportedly (e.g. [1]) the LOCK handling is special to %cr0 / %cr8 only.
Deal with it this way also in assembler and disassembler.
For the assembler also introduce a separate feature indicator: Not all
64-bit CPUs support this insn form; only most AMD (and presumably all
Hygon) ones do. Register names %cr9 ... %cr15 thus become invalid outside
of 64-bit mode altogether (unprefixed forms become ordinary symbol names),
while %cr8's availability outside of 64-bit mode now depends on the new
feature indicator.
For the disassembler don't limit this handling to non-64-bit modes. Use
of LOCK is similarly permitted in 64-bit mode. Instead don't handle LOCK
this way when "intel64" was specified as an option.
Alan Modra [Fri, 17 Jul 2026 00:07:37 +0000 (09:37 +0930)]
loongarch gcc-4.9 build error
gas/config/tc-loongarch.c: In function ‘md_apply_fix’:
gas/config/tc-loongarch.c:1886:7: error: a label can only be part of a statement and a declaration is not a statement
unsigned int subtype;
^
Tom Tromey [Thu, 2 Jul 2026 19:32:25 +0000 (13:32 -0600)]
Document remote protocol pid and thread id sizes
The recent ptid work came from a bug where a problem was observed due
to sign extension. That bug also suggested documenting the guaranteed
range of thread- and process-ids in the remote protocol.
This patch documents these as being 32-bit values at minimum. I also
added static asserts to ensure this is true -- note that although
'int' may be 16 bit per the C standard, I doubt gdb would build on
such a host.
I didn't specify a maximum because it is host-dependent. This is
perhaps something to change, and while I do have some work in this
area, it's quite invasive. Also, while widening the range here would
be good, it would also be incompatible in a sense, where a newer
protocol implementation may end up using values not supported by older
versions of gdb. Perhaps one idea would be to simply change these
both to int32_t and move on.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33979 Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Xi Ruoyao [Tue, 14 Jul 2026 15:51:32 +0000 (23:51 +0800)]
LoongArch: only insert align section for ld -r if an input has R_LARCH_ALIGN or R_LARCH_RELAX
Commit 8bf4b69718d4 ("LoongArch: Fix relaxation alignment with ld -r (PR
33236)") has broken the kernel modules on Debian sid. The expectation
of the kernel is all the source files which would be linked into a
module are compiled with -mno-relax so the module should not contain
R_LARCH_ALIGN, thus the module loader rejects any module containing
R_LARCH_ALIGN.
To restore the correctness of the expectation, only insert the align
section if an input has R_LARCH_ALIGN or R_LARCH_ALIGN (i.e. bytes may
be removed from that input). Regardless of the kernel modules, it also
does not make too much sense to bloat the output with NOPs and
R_LARCH_ALIGN if no input ever contains R_LARCH_ALIGN and R_LARCH_ALIGN
anyway.
libctf: bounds-check forward ctt_type before indexing pop[]
init_static_types_internal() walks the CTF type section that comes
directly from an object file's .ctf section. During the first counting
pass it treats a CTF_K_FORWARD record's ctt_type as the CTF_K_* kind of
the forwarded tag and bumps the corresponding population count:
if (kind == CTF_K_FORWARD)
pop[tp->ctt_type]++;
pop[] is a fixed-size stack array with CTF_K_MAX + 1 (64) entries, but
ctt_type is a 32-bit value read straight from the file and is never
validated. A crafted dict whose forward record carries a ctt_type
greater than CTF_K_MAX therefore causes an out-of-bounds write to the
stack at an attacker-controlled index.
The type walk is reachable from ctf_bufopen()/ctf_open(), i.e. whenever
libctf opens a dict: ld while linking CTF, and objdump/nm --ctf. The
second pass already tolerates an out-of-range ctt_type (ctf_name_table()
has a default case), so only this first-pass index was unguarded.
Reject a ctt_type outside the valid kind range as ECTF_CORRUPT, matching
the existing corruption handling in the same loop.
Reproduced with a 65-byte in-memory dict (one CTF_K_FORWARD record whose
ctt_type is 64) passed to ctf_bufopen(). Before the fix, AddressSanitizer
reports a stack-buffer-overflow at ctf-open.c:759 overflowing pop[64];
after the fix ctf_bufopen() returns ECTF_CORRUPT. Valid forwards
(ctt_type of CTF_K_STRUCT/UNION/ENUM) and the boundary value CTF_K_MAX
still open successfully.
Alan Modra [Wed, 15 Jul 2026 21:57:58 +0000 (07:27 +0930)]
readelf.c gcc-4.9 compile error
gcc-4.9 doesn't like an empty initialiser.
binutils/readelf.c: In function ‘process_relocs’:
binutils/readelf.c:10229:5: error: missing initializer for field ‘sh_name’ of ‘Elf_Internal_Shdr’ [-Werror=missing-field-initializers]
Elf_Internal_Shdr section = {};
Tom de Vries [Tue, 14 Jul 2026 08:43:14 +0000 (10:43 +0200)]
[gdb/exp] Handle recursive namespace import
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of variable xxx we get:
...
$ gdb -q -batch a.out -ex start -ex "print xxx"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
No symbol "xxx" in current context.
...
The symbol xxx is defined in namespace mod_a, so it's available as:
...
(gdb) p mod_a::xxx
$1 = 10
...
and namespace mod_b uses namespace mod_a, so it's available as:
...
(gdb) p mod_b::xxx
$2 = 10
...
Then main uses namespace mod_b so xxx should also be available in main, but
it's not.
The problem happens here in cp_lookup_symbol_via_imports:
...
Thread 1 "gdb" hit Breakpoint 1, cp_lookup_symbol_via_imports (scope=0x5f43d0 "",
name=0xfffffffface0 "xxx", block=0x2fba5a0, domain=..., search_scope_first=0,
declaration_only=0, search_parents=1, found_symbols=...)
at /home/vries/gdb/src/gdb/cp-namespace.c:505
505 cp_lookup_symbol_via_imports (current->import_src, name,
...
We're about to follow the "using namespace mod_b" statement:
...
(gdb) p *current
$1 = {import_src = 0x2ed2140 "mod_b", import_dest = 0x66e910 "", alias = 0x0,
declaration = 0x0, next = 0x0, decl_line = 5, searched = 1,
excludes = {0x0}}
...
But it does so using the current block, which is the function block for main:
...
(gdb) p block->function ().m_name
$7 = 0x2f8bc20 "main()"
...
and the block containing the "using namespace mod_a" statement is the static
block.
Fix this by additionally iterating over the static and global blocks instead
of only using the current block.
Tom de Vries [Tue, 14 Jul 2026 08:43:14 +0000 (10:43 +0200)]
[gdb/exp] Fix ignoring of incorrect namespace prefix
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of non-existent variable mod_a::yyy, we get:
...
$ gdb -q -batch a.out -ex start -ex "print mod_a::yyy"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
$1 = 20
...
The problem is in cp_lookup_symbol_via_imports, where we decide that the
"using namespace mod_b" from main is applicable in scope mod_a.
More concretely, cp_lookup_symbol_via_imports is called with:
- scope == "mod_a",
- name == "yyy", and
- block.m_function.m_name == "main()",
and when looking at "using namespace mod_b":
...
(gdb) p *current
$12 = {import_src = 0x344018c "mod_b", import_dest = 0x1b477a0 "",
alias = 0x0, declaration = 0x0, next = 0x0, decl_line = 5,
searched = 0, excludes = {0x0}}
...
we hit "directive_match = true" because strlen (current->import_dest) == 0.
Fix this by being more strict in the calculation of directive_match:
...
if (len == 0)
- directive_match = true;
+ {
+ const char *current_scope = (block->function_block () != nullptr
+ ? block->scope ()
+ : nullptr /* Don't know. */);
+ directive_match = (current_scope != nullptr
+ ? streq (scope, current_scope)
+ : true /* Assume there's a match. */);
+ }
...
which gets us:
- current_scope == "", and
- directive_match == false,
because scope == "mod_a", so streq (scope, current_scope) == false.
As is clear from the code, in case we don't know the current scope, we assume
there's a match. This may be harmless, or this may describe a cornercase we
haven't run into yet. If so, it's a pre-existing issue.
The new test-case contains regression tests for:
- PR34051, and
- PR34034 for which it contains a kfail.
Tom de Vries [Tue, 14 Jul 2026 08:43:14 +0000 (10:43 +0200)]
[gdb] Break up complex assignment in cp_lookup_symbol_via_imports
In cp_lookup_symbol_via_imports, we have a complex assignment:
...
directive_match = (search_parents
? (startswith (scope, current->import_dest)
&& (len == 0
|| scope[len] == ':'
|| scope[len] == '\0'))
: streq (scope, current->import_dest));
...
Writing it like this makes it:
- harder to comment on parts of the expression, and also
- harder to understand and modify it.
Also, len == 0 makes the startswith redundant, so that part of the expression
can be hoisted. Doing so makes it clear that scope is not compared against in
all cases.
Fix this by breaking this up into three separate assignments:
...
if (search_parents)
{
if (len == 0)
directive_match = true;
else
directive_match = (startswith (scope, current->import_dest)
&& (scope[len] == ':'
|| scope[len] == '\0'));
}
else
directive_match = streq (scope, current->import_dest);
...
This optimization is enabled with -O, -O2 and -Os.
2. Since 0xb0 mov with 32-bit destination registers zero-extends 32-bit
immediate to 64-bit destination register, we can use it to encode 64-bit
mov with 32-bit immediates. This optimization is enabled with -O, -O2
and -Os.
3. Since the upper bits of destination registers of VEX128 and EVEX128
instructions are extended to zero, if all bits of destination registers
of AVX256 or AVX512 instructions are zero, we can use VEX128 or EVEX128
encoding to encode AVX256 or AVX512 instructions. When 2 source
registers are identical, AVX256 and AVX512 andn and xor instructions:
VOP %reg, %reg, %dest_reg
can be encoded with
VOP128 %reg, %reg, %dest_reg
This optimization is enabled with -O2 and -Os.
4. 16-bit, 32-bit and 64-bit register tests with immediate may be
encoded as 8-bit register test with immediate. This optimization is
enabled with -Os.
These optimizations were intended for compiler generated assembly codes.
The optimization changes may take a long time to be put into GCC. The
similar SSE move encoding optimization for GCC was first proposed in
Feb, 2019:
i386: Properly encode vector registers in vector move
Such optimizations are useful for compiler generated codes since they
work with released versions of GCC which don't have such optimized
encoding. We assume that it is safe to use on compiler generated codes.
When we are informed that an assembler optimization introduces a
significant drawback, we will investigate its drawbacks and benefits.
If its drawbacks outweigh its benefits, such optimization should be
removed.
has special meanings and shouldn't be changed by assembler even when
assembler optimization is enabled. Since there are no any evidences
to show its benefits, we can't say that it is useful at all. This
patch disables this optimization, which may be enabled with a different
option.
gas/
PR gas/34343
* config/tc-i386.c (optimize_for_disabled_optimizations): New.
(optimize_encoding): Optimize "xchg %rN, %rN" to "mov %rN, %rN"
only if optimize_for_disabled_optimizations isn't 0.
* testsuite/gas/i386/optimize-2b.d: Updated.
* testsuite/gas/i386/x86-64-optimize-3b.d: Likewise.
Tom de Vries [Mon, 13 Jul 2026 17:09:35 +0000 (19:09 +0200)]
[gdb/exp] Fix ns var lookup when stopped at inlined fn call
Consider test.c:
...
1 namespace mod_a {
2 int xxx = 10;
3 }
4
5 static inline int __attribute__((always_inline))
6 inlined () {
7 return 0;
8 }
9
10 int main () {
11 using namespace mod_a;
12 int res = inlined ();
13 return res + xxx;
14 }
...
compiled with "g++ test.c -g".
Trying to print variable xxx at line 12 fails:
...
$ gdb -q -batch a.out -ex start -ex "p xxx"
...
Temporary breakpoint 1, main () at test.c:12
12 int res = inlined ();
No symbol "xxx" in current context.
...
The problem is here in function using_direct::valid_line:
...
CORE_ADDR curr_pc = get_frame_pc (get_selected_frame (nullptr));
symtab_and_line curr_sal = find_sal_for_pc (curr_pc, 0);
return (decl_line <= curr_sal.line)
|| (decl_line >= boundary);
...
where we're trying to decide whether "using namespace mod_a" is applicable.
The decl_line is 11, as expected.
If curr_sal.line were 12, decl_line <= curr_sal.line would be true, and
using_direct::valid_line would return true.
But instead, curr_sal.line is 7.
This is sort of correct, the current PC maps to that line. It's just that gdb
steps into inlined functions in two steps, each with identical PC:
- once stopping at the call site (line 12 in this case)
- once stopping at the PC line (line 7 in this case)
The function using_direct::valid_line doesn't apply this logic, and
consequently line 7 is used for both cases.
Tom de Vries [Mon, 13 Jul 2026 13:29:14 +0000 (15:29 +0200)]
[gdb/testsuite] Fix FAIL in gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
On x86_64-linux, I ran into the following FAIL:
...
(gdb) cont
Continuing.
[Switching to Thread 0x7ffff7cbe6c0 (LWP 3534988)]
Thread 2 "sw-watchpoint-s" hit Watchpoint 3: watched_global
Old value = 0
New value = 1
0x00007ffff7d514bf in futex_wait () at ../sysdeps/nptl/futex-internal.h:146
146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) PASS: $exp: target-non-stop=auto: displaced-stepping=auto: \
continue to watchpoint
break 64
No compiled code for line 64 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: $exp: target-non-stop=auto: displaced-stepping=auto: \
gdb_breakpoint: set breakpoint at 64
...
[ The FAIL initially reproduced only under heavy system load (simulated using
stress -c $(grep -c ^processor: /proc/cpuinfo)), but then I found that
changing the delay in $srcfile from 1 second to 1 millisecond also reproduced
it fairly reliably. Using this approach, I managed to reproduce both on
x86_64-linux and aarch64-linux. ]
The test-case tries to set a breakpoint at $srcfile:64, using just "64", but
that doesn't work because the inferior is not stopped in $srcfile.
This can be trivially fixed by using $srcfile:64 instead, and indeed, this is
what this patch does.
However, that fix is only correct if gdb is indeed allowed to report a stop in
thread 2.
This is a question I found difficult to answer.
I found some text in the docs [1] that seems related to the test-case
scenario:
...
Warning: In multi-threaded programs, software watchpoints have only limited
usefulness. If GDB creates a software watchpoint, it can only watch the value
of an expression in a single thread. If you are confident that the expression
can only change due to the current thread’s activity (and if you are also
confident that no other thread can become current), then you can use software
watchpoints as usual. However, GDB may not notice when a non-current thread’s
activity changes the expression. (Hardware watchpoints, in contrast, watch an
expression in all threads.)
...
After reading this text, my impression was that gdb shouldn't report a stop in
thread 2, because:
- GDB "can only watch the value of an expression in a single thread",
- the expression can only change due the current thread's activity (thread 1),
and
- thread 2 cannot become current, it just spins and there's no breakpoint set
in the range where it spins.
However, in the test-case I came across the following text:
...
# The final continue, with the software watchpoint set, so that
# GDB single-steps all threads (if the target is non-stop).
...
Indeed, the test-case iterates over some dimensions:
...
foreach_with_prefix target-non-stop {auto on off} {
foreach_with_prefix displaced-stepping {auto on off} {
test ${target-non-stop} ${displaced-stepping}
}
}
...
and disregarding the auto, the FAIL reproduces with both displaced-stepping on
and off, but only with target-non-stop on.
So we have the default non-stop off, and target-non-stop on.
The documentation says about this [2]:
...
set non-stop off, target operating in non-stop mode
When a thread hits a breakpoint, finishes a step, etc., the target does not
immediately stop all other threads. If, while processing the event, infrun
decides the stop should be reported to the user, it then explicitly stops all
threads, just before presenting the stop to the user; otherwise, infrun
re-resumes the stopped thread. This scenario is also called “all-stop on top
of non-stop”.
...
I was not able to deduce why in this situation and in presence of a software
watchpoint all threads should be single stepping, so I asked Claude Code.
It gave the following background information:
- in the pure all-stop case (set non-stop off, target operating in all-stop
mode), in presence of a software watchpoint:
- the current thread single-steps
- the other threads stay stopped
- consequently, only modifications by the current thread are detected,
- in the all-stop on non-stop case (set non-stop off, target operating in
non-stop mode), in presence of a software watchpoint:
- all threads single-step
- consequently, modifications by any thread are detected, but it's not
possible to attribute the modification to any specific thread, so gdb
attributes it to the thread whose stop happens to be processed.
This adequately explains the behavior in the test-case.
I suspect that the warning text in the documentation needs updating, because
AFAICT it doesn't cover the "set non-stop off, target operating in non-stop
mode" behavior described above.
Tom de Vries [Mon, 13 Jul 2026 13:23:12 +0000 (15:23 +0200)]
[gdb] More codespell fixes
I did this in gdb/pyproject.toml:
...
+regex = "[a-zA-Z0-9\\-']+"
...
allowing us to detect things like 'gcs_availabe':
...
$ echo gcs_availabe | codespell --regex="[a-zA-Z0-9\-']+" -
1: gcs_availabe
availabe ==> available
...
and ran:
...
$ codespell --toml gdb/pyproject.toml gdb*
...
and manually fixed fallout.
Tom de Vries [Mon, 13 Jul 2026 13:06:35 +0000 (15:06 +0200)]
[gdb] Use using in compat_x32_clock_t typedef
In commit 6c85ef111b0 ("[gdb] Use using instead of typedef"), I did:
...
-typedef long __attribute__ ((__aligned__ (4))) compat_x32_clock_t;
+using compat_x32_clock_t = long __attribute__ ((__aligned__ (4)));
...
which I had to revert because clang ignores the attribute in this variant.
Pedro suggested instead using:
...
using compat_x32_clock_t [[gnu::aligned (4)]] = long;
...
which does work with both clang and gcc.
[ Note that it's not a question of how the attribute is worded, this also works:
...
using compat_x32_clock_t __attribute__ ((__aligned__ (4))) = long;
...
It's just a question of where the attribute is placed. ]
Fix this by using Pedro's suggestion.
Suggested-By: Pedro Alves <pedro@palves.net> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Mon, 13 Jul 2026 11:33:42 +0000 (13:33 +0200)]
[gdb] Move ChangeLog files to archive dir
We stopped updating ChangeLog files in 2021, and they are no longer
maintained.
If I want to see history, I use git log, so I don't use them for any purpose.
And they're in my way when I'm searching for files, grepping, or refactoring
using sed.
Move them out of the way, into a root-level directory named archive
(alternative names: legacy, deprecated, attic, stale, historical,
unmaintained).
Result of:
...
for f in $(find gdb* -name "ChangeLog*"); do
dir=$(dirname $f)
f=$(basename $f)
u=archive/$dir
mkdir -p $u
git mv $dir/$f $u/$f
done
...
Also drop ignoring ChangeLog files in some pre-commit tools.
A less impactful but also less effective change would be to move <dir>/ChangeLog
into <dir>/archive/ChangeLog.
Tom de Vries [Mon, 13 Jul 2026 11:11:06 +0000 (13:11 +0200)]
[pre-commit] Remove duplication in config file
In a recent commit, I introduced anchor/alias pairs in
.pre-commit-config.yaml, with short non-descriptive names for local use:
...
- - id: check-include-guards
- name: check-include-guards
+ - id: &id0 check-include-guards
+ name: *id0
...
Use anchors and aliases a bit more to remove duplication, now using more
descriptive names for non-local uses.
Yaml also supports defining an anchor for more than one field, which result in
cleaner code:
...
+python-files: &python-files
+ types_or: [file]
+ files: '^gdb/.*\.py(\.in)?$'
+
...
- id: black
- types_or: [file]
- files: '^gdb/.*\.py(\.in)?$'
+ <<: *python-files
...
but unfortunately pre-commit generates a warning "[WARNING] Unexpected key(s)
present at root: python-files" for this [1].
Tom de Vries [Mon, 13 Jul 2026 07:40:09 +0000 (09:40 +0200)]
[gdb/testsuite] Fix isort fail in gdb.python/py-frame.py
Result of:
...
$ pre-commit run isort --all-files
isort...................................................................Failed
- hook id: isort
- files were modified by this hook
Alan Modra [Sun, 12 Jul 2026 08:55:35 +0000 (18:25 +0930)]
Re: readelf: Save and dump the original section header values
This started as removing the imperative "Ignore the.." from
validate_section_info warnings, and making them a little less work for
translators. I also decided it wasn't worth reporting specifics about
a malloc failure when allocating a relatively small fixed size buffer.
It would be different if some large chunk of file data caused a malloc
fail.
The patch also fixes a potential orig_section_headers buffer overflow,
caused by allocating a single element array when probing, hitting some
early error in process_file_header, then attempting to access it as an
array of e_shnum entries in free_filedata.
* readelf.c (save_original_section_header_values): Use xmalloc
rather than reporting a more specific error. Drop now unused
function parameters.
(validate_section_info): Delete "dynamic" and "probe" params.
Redo warning messages. Don't save orig header for fake
section header passing relr dynamic tags. Avoid possible
arithmetic overflow when checking sh_size.
(get_32bit_section_headers): Don't allocate orig_section_headers
or call validate_section_info when probing.
(get_64bit_section_headers): Likewise.
(process_relocs): Update validate_section_info call when
handling relr.
Jan Dubiec [Sat, 11 Jul 2026 00:53:03 +0000 (02:53 +0200)]
H8: Set H8/300H as the default architecture for the H8 family.
H8/300H uses 32-bit addresses in its default advanced mode, whereas
H8/300 uses 16-bit addresses. Updates affected test cases accordingly.
bfd/
* cpu-h8300.c: Set H8/300H as the default architecture
for the H8 family.
gas/
* config/tc-h8300.c: Set H8/300H as the default architecture
for the H8 family.
* NEWS: Add info about the above change.
ld/
* configure.tgt: Set H8/300H as the default architecture
for the H8 family.
* NEWS: Add info about the above change.
* testsuite/ld-elf/elf.exp: Expect 32-bit addresses/pointers
for H8 on __patchable_function_entries tests.
Matthieu Longo [Thu, 2 Jul 2026 15:24:31 +0000 (16:24 +0100)]
gdb/linux-tdep: change linux_fill_prpsinfo to return bool
Change linux_fill_prpsinfo() to return a boolean instead of an integer, since
it only reports success or failure.
Replace the returned integer values 1 and 0 with true and false respectively.
Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
execl-update-breakpoints.c is compiled as both
execl-update-breakpoints1 and execl-update-breakpoints2.
execl-update-breakpoints1 checks to see if the last character in its
filename is '1', and if so, replace it with '2' and execl the result.
On Windows, this fails to take into account that the filename may have
an ".exe" extension. The result is that the execl-update-breakpoints1
executable execs itself forever.
This patch fixes it by taking the .exe extension into account.
(Note that neither native Windows nor Cygwin support following execs,
and maybe the testcase will eventually be skipped there, but even
then, if someone enables follow-exec testing there, we'd want it to
handle the .exe extension, so I think it's better to adjust the
testcase than not.)
Now, on e.g. GNU/Linux, if you run execl-update-breakpoints1 manually,
you'll see that it also execs forever, but this time, what happens is
that execl-update-breakpoints1 execs execl-update-breakpoints2, and
then it's execl-update-breakpoints2 that execs itself forever. There
is no reason for execl-update-breakpoints2 to exec. It's just that
the testcase is assuming that the process is killed when the testcase
is over. It's just cleaner if execl-update-breakpoints1 execs
execl-update-breakpoints2, and then execl-update-breakpoints2 just
cleanly exits. The patch does that too.
And then, the test program should really be erroring out if neither
'1' nor '2' is found at the tail of the executable. Done too.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Id88830cd8dff2c63dd69b827d4ba79743aa9ebca
Alice Carlotti [Thu, 9 Jul 2026 17:27:43 +0000 (18:27 +0100)]
aarch64: Add support for FEAT_SME_FA64
Add "+sme-f64" to the list of architecture extensions. This has already
been supported in LLVM for several years.
We don't need to update the feature requirements for any opcodes,
because FEAT_SME_FA64 only enables instructions that were already
available in non-streaming mode, and the feature checks don't know what
mode an instruction will be run under.
Alice Carlotti [Wed, 18 Feb 2026 14:25:58 +0000 (14:25 +0000)]
aarch64: Drop "" from hint option hash table
An empty string is the only option where the upper and lower case forms
are identical, so this allows the upper case insertion logic to be
simplified as well.
Alice Carlotti [Fri, 15 May 2026 02:52:30 +0000 (03:52 +0100)]
aarch64: Remove disassembly restriction on OP_MOV_Z_Zi
Disassembly for the OP_MOV_Z_Zi opcode artificially rejected a zero
index value, to indicate that the preferred disassembly uses a different
alias. This is more naturally indicated by specifying the other alias
as a higher priority.
Update the alias priority, and remove the zero check and the now-unused
OP_MOV_Z_Zi enum value.
Alice Carlotti [Fri, 15 May 2026 16:09:41 +0000 (17:09 +0100)]
aarch64: Inline all FLD_* uses in aarch64-tbl.h
Inline all non-constant field definitions into operand field lists, and
remove the resulting unused FLD_* macros. For brevity, define FLD as an
alias for AARCH64_FLD in aarch64-gen.c.
Alice Carlotti [Fri, 15 May 2026 16:09:30 +0000 (17:09 +0100)]
aarch64: Write AARCH64_FIELD calls to aarch64-opc-2.c
Parse the operand field lists in aarch64-gen.c, and rewrite the content
to aarch64-opc-2.c using AARCH64_FIELD calls. This allows aarch64-tbl.h
to use shorthand macros without exporting them elsewhere.
Alice Carlotti [Wed, 8 Oct 2025 23:37:21 +0000 (00:37 +0100)]
aarch64: Remove aarch64_field_kind indirection
Replace all uses of the aarch64_field_kind enum with direct uses of an
aarch64_field struct instead. Add macro defines mapping the old enum
names to their corresponding aarch64_field values, to reduce the initial
diff. These can be substituted directly into their uses in subsequent
patches.
Once the macro defines are replaced, this should make it simpler to read
the code, because it will no longer be necessary to look in a separate
table to find out which opcode bits a field actually uses. This has
been a growing problem over the years - originally there was a simpler
correspondence between field names and positions, but as the
architecture has grown it has become harder to guess a field's position
from it's name alone.
Pedro Alves [Fri, 3 Oct 2025 16:45:39 +0000 (17:45 +0100)]
gdb/hip: Prepare for DWARF-assembler-based HIP testcases
Compiling a testcase with debug info (by passing passing "debug" as
gdb_compile option) has the effect of passing -g to the compiler. -g
in turn enables an LLVM option that is essential for debugging:
'-mllvm -amdgpu-spill-cfi-saved-regs'.
That option affects code generation, and some features of the DWARF
assembler machinery rely on code generated by the compiler without -g
to be the exact same as the code generated with -g.
This patch addresses that by always compiling with the LLVM option
that -g would enable.
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
Change-Id: I64a938edf97c85d0ea9fc34b37071daa560de7e7
H.J. Lu [Thu, 2 Jul 2026 02:14:10 +0000 (10:14 +0800)]
readelf: Save and dump the original section header values
validate_section_info clears the garbage values in the section header
to avoid crash later. Save and dump the original section header values
to make the garbage values in the section header visible when dumping
section headers.
Note: orig_section_headers, instead of sane_section_headers, is added to
filedata since filedata->section_headers is used in many places. Replace
filedata->section_headers with filedata->sane_section_headers requires
a much bigger change.
* readelf.c (filedata): Add orig_section_headers.
(save_original_section_header_values): New.
(validate_section_info): Add a pointer to the original section
header and call save_original_section_header_values to save the
original section header values before clearing the section header
fields.
(get_32bit_section_headers): Allocate the original section header
buffer. Pass the original section header pointer to
validate_section_info.
(get_64bit_section_headers): Likewise.
(process_section_headers): Dump the original section header
values if they exist.
(process_relocs): Pass a dummy original section pointer to
validate_section_info.
(free_filedata): Free filedata->orig_section_headers.
* testsuite/binutils-all/corrupt-1.elf.bz2: New file.
* testsuite/binutils-all/corrupt-1.r: Likewise.
* testsuite/binutils-all/readelf.exp: Run corrupt-1.elf test.
Ronald Hecht [Mon, 15 Jun 2026 07:04:01 +0000 (09:04 +0200)]
gdb: z80: Fix endless loop in frame unwinder and validate saved register types
In z80_frame_unwind_cache, the loop scanning for the frame base pointer
(for (;; ++sp)) could run into an endless loop or scan too far if the
termination condition (sp < this_base) was not met due to corrupted
or unexpected stack layouts. This patch introduces a loop_count to
limit the scan to a maximum of 2 * addr_len iterations.
Additionally, when iterating through saved registers to adjust their
offsets into concrete addresses, the code now explicitly checks if
the register actually holds an address using is_addr() before calling
addr(). This prevents potential assertions or undefined behavior for
registers that do not contain valid address data.
gdb/ChangeLog:
* z80-tdep.c (z80_frame_unwind_cache): Limit stack scanning
to 2 * addr_len iterations to prevent endless loops. Check
is_addr() before adjusting saved register addresses.
RISC-V: Check for conflicting extensions when the linker merges arch attributes
The linker validates the arch of each input when parsing it, but never
checks the merged arch as a whole, so conflicting extensions could
silently slip through. The merge can even imply extensions that
neither input implies alone, e.g. `c' from one input and `d' from
another imply `zcd', which conflicts with `zcmp'.
After merging the input archs, add the implicit extensions to the
merged arch, then run the conflict checks on it and reject the merge
if any conflict is found. Add tests for such merges.
RISC-V: Release subset lists on all paths when the linker merges arch attributes
riscv_merge_arch_attr_info returned early on the error paths without
releasing in_subsets, out_subsets and merged_subsets, so the nodes
already added to them were leaked. The leaked nodes of in_subsets
and out_subsets also carry over into the next merge.
Route every post-parse error path through a single cleanup exit that
releases all three subset lists, and drop the now-redundant reset of
merged_subsets at entry.
projects / thirdparty / binutils-gdb.git / log
