gdb: convert address_class_type_flags_to_name to address_class_id_to_name
In type instance flags, two bits are allocated for encoding the
address class. Although defined like a bitmask, those two bits in
fact represent an architecture-specific enum value. As a step towards
making this conceptual separation clear, refactor the gdbarch method
'address_class_type_flags_to_name'. This method is used for returning
the name for the address class id encoded in type instance flags.
Make this clear by passing it the address class id, instead of the
whole flags.
gdb: use type instance macros to query const, volatile, restrict
In two cases in compile/compile-c-types.c and
compile/compile-cplus-types.c, we query if a type is const, volatile,
or restrict using bitmasks. For such read-only queries, there are
macros. Use them for code uniformity. The new code may be slightly
less optimal, but I don't think this would matter in practice. This
is a code cleanup step in a series.
Markus Metzger [Wed, 22 Jul 2026 07:39:24 +0000 (07:39 +0000)]
gdb: fix maint info btrace
The 'maint info btrace' command forgets to check whether the trace has
already been decoded and keeps appending the same trace to the packet
history at every command. Fix that.
Alan Modra [Wed, 22 Jul 2026 23:53:52 +0000 (09:23 +0930)]
PR 30308 more unbounded recursion
oss-fuzz found another case where i386_intel_simplify and
i386_intel_simplify_symbol recurse until stack overflow. This time
recursion happened on an expression with both X_add_symbol and
X_op_symbol, the call stack alternating on the two symbols. Fix
that case too.
* config/tc-i386-intel.c (i386_intel_simplify): Mark X_add_symbol
whenever calling i386_intel_simplify_symbol for X_op_symbol.
* testsuite/gas/i386/intel-equ-loop.s,
* testsuite/gas/i386/intel-equ-loop.l: Extend testcase.
Tom Tromey [Tue, 21 Jul 2026 13:32:58 +0000 (07:32 -0600)]
Export SHELL before invoking lineno.sh
A user reported that building the sim failed, because their shell was
not sh-compatible. In particular, lineno.sh uses $SHELL to invoke
another script.
This patch arranges for SHELL to be exported when invoking lineno.sh,
ensuring that the correct shell is used.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34407 Approved-By: Andrew Burgess <aburgess@redhat.com>
GDB: aarch64: Fix inferior function call if GCS is present but disabled
On AArch64, even if the Guarded Control Stack feature is present on the
system the inferior may not have enabled it.
There's a bug in GDB's GCS support in that if the system supports GCS,
GDB will always push a GCS entry when doing an inferior function call
even if the inferior doesn't have it enabled. This causes inferior
function calls to fail. E.g.:
(gdb) p foo ()
Can't write to Guarded Control Stack.
The error message is because the GCSPR doesn't point to a valid memory
address.
Fix by checking whether GCS is enabled in the inferior before trying to
push a GCS entry.
Regression tested on an aarch64-linux-gnu QEMU VM with GCS present.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Tom Tromey [Wed, 13 May 2026 15:57:06 +0000 (09:57 -0600)]
Remove for_each_thread
This patch removes the for_each_thread function, changing the callers
to use 'foreach' loops instead. In general I think loops with
iterators should be preferred over callback-based approaches -- they
are easier to read and often result in less source code as well. For
example, in this patch a helper function is inlined into its sole
caller.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Pedro Alves [Wed, 22 Jul 2026 15:08:55 +0000 (16:08 +0100)]
gdb/testsuite: Use file_rename_atomic in gdb_do_cache too
An earlier commit ("Windows: Fix set_unbuffered_mode.o file rename
race") introduced file_rename_atomic to ignore EBUSY when multiple
parallel workers race to rename their identical copy of a file to a
shared final destination, and converted the two atomic renames in
gdb.exp to use it.
gdb_do_cache in cache.exp does the same thing: in GDB_PARALLEL mode,
each worker writes the results cache to a per-pid temporary file and
then atomically renames it into place, so it can hit the same EBUSY
race on Windows. It was missed by that commit.
Fix it by using file_rename_atomic there too.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I9780ed4989f9c4e9daf7143280cd63a65c6918ed
The atomic file rename for set_unbuffered_mode.o can fail in this scenario:
| process A | process B |
|---------------------------------+---------------------------|
| compiles temp .o | compiles temp .o |
| moves .o | |
| links with .o file (locks file) | moves .o (fails w/ EBUSY) |
Here's what it looks like:
builtin_spawn -ignore SIGHUP /mingw64/bin/clang -fdiagnostics-color=never -Wno-unknown-warning-option -w -c -o /c/msys2/home/alves/gdb/build-testsuite/temp/53930/set_unbuffered_mode-c.o /c/rocgdb/src/gdb/testsuite/lib/set_unbuffered_mode.c
pid is 54259 -54259
pid is -1
output is status 0
ERROR: tcl error sourcing /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp.
ERROR: tcl error code POSIX EBUSY {file busy}
ERROR: error renaming "/c/msys2/home/alves/gdb/build-testsuite/temp/53930/set_unbuffered_mode.o" to "/c/msys2/home/alves/gdb/build-testsuite/set_unbuffered_mode.o": file busy
while executing
"file rename -force -- $unbuf_obj $gdb_saved_set_unbuffered_mode_obj"
(procedure "gdb_compile" line 559)
invoked from within
"gdb_compile $source $dest $type $options"
(procedure "gdb_compile" line 42)
invoked from within
"$func $objects "${binfile}" executable $options"
(procedure "build_executable_from_specs" line 50)
invoked from within
"build_executable_from_specs {*}$arglist"
(procedure "build_executable" line 11)
invoked from within
"build_executable "failed to build" ${testfile} $srcfile"
(file "/c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp" line 21)
invoked from within
"source /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp"
invoked from within
"catch "uplevel #0 source $test_file_name" msg"
UNRESOLVED: gdb.base/step-over-no-symbols.exp: testcase '/c/rocgdb/src/gdb/testsuite/gdb.base/step-over-no-symbols.exp' aborted due to Tcl error
If we get EBUSY, it's because another parallel worker already managed
to build and move its set_unbuffered_mode.o copy to the final
destination. So fix it by simply ignoring EBUSY.
gdb_windows_manifest_obj has similar code with the same problem, so
put the atomic rename in a new file_rename_atomic procedure, and use
it from both places.
(Note: both the set_unbuffered_mode.o path and
gdb_windows_manifest_obj are Windows-specific.)
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I6a32d17364a19337d7f55e4376de736e1cca799d
Pedro Alves [Fri, 10 Jul 2026 11:28:34 +0000 (12:28 +0100)]
gdb/Windows testsuite: Embed asInvoker manifest in test executables
Running gdb.base/execl-update-breakpoints.exp on Windows 11 shows this
FAIL:
(gdb) run
Starting program: .../execl-update-breakpoints1.exe
Error creating process .../execl-update-breakpoints1.exe (error 740): The requested operation requires elevation.
(gdb) FAIL: gdb.base/execl-update-breakpoints.exp: runto: run to main
Error 740 is ERROR_ELEVATION_REQUIRED.
Windows has an "installer detection" heuristic that refuses to launch
executables whose file name contains keywords like "update", "setup"
and "install" without elevation (admin rights), unless the PE embeds
an application manifest declaring requestedExecutionLevel="asInvoker".
Some older Microsoft documentation claims the heuristic only applies
to 32-bit binaries, but what I observe is that:
- It triggers with 64-bit PEs on current Windows.
And also:
- It matches the word (e.g. "update") as a substring anywhere in the
file name, not just as a prefix.
- It is not drive-dependent. I thought moving the executable to a
dev drive might suppress the check, but it does not.
I saw this problem first in a downstream ROCgdb testcase, and there I
worked around it by renaming that particular testcase. This is the
second case now, so rather than teach individual testcases to avoid
the "bad" words, fix it once, centrally, in a way that is independent
of the executable's file name.
The Microsoft-sanctioned escape hatch is to embed an application
manifest that declares the "asInvoker" execution level. That's what
this commit does, it makes gdb_compile embed one in every Windows
executable it builds.
How the manifest gets embedded depends on the linker. There are two
ways:
- GNU ld can't embed a manifest by itself, so compile it into a
resource object with windres and link that in.
- lld-link is able to embed one directly, with the /manifest:embed
and /manifestinput options.
Since it's not guaranteed that clang always links with lld-link, and
conversely, gcc may also link with lld-link, gdb_compile picks between
the two by probing what the linker accepts, rather than keying off the
compiler or the target.
This whole issue only reproduces with some toolchains, because some
MinGW or Cygwin installations already embed an equivalent manifest of
their own, via a default-manifest.o that the gcc spec links in. That
object comes from the separate windows-default-manifest package, so
whether it is embedded depends on the installation rather than the gcc
version.
Since we're adding a manifest, might as well declare the supported
Windows versions there too (a compatibility section listing
per-version GUIDs), like default-manifest.o does. Without those, the
version-reporting APIs (GetVersionEx and friends) cap out at Windows
8. We should probably add such a manifest to GDB itself too, at some
point.
Approved-By: Eli Zaretskii <eliz@gnu.org>
Change-Id: Ic0afc925136a61c259cb8b6681627dc1775a8445
Pedro Alves [Tue, 14 Jul 2026 19:46:28 +0000 (20:46 +0100)]
gdb.base/callfuncs.exp: Exercise "long double"
gdb.base/callfuncs.exp tests calling functions that take and return
floating point arguments, but only for float and double. Add long
double too, so that GDB's handling of the type in inferior function
calls is exercised.
On x86_64-pc-windows-msvc, without the fix that teaches GDB about the
correct size of "long double", we get:
$ grep FAIL gdb.sum
FAIL: gdb.base/callfuncs.exp: noproto: p ((int (*) ()) t_long_double_values)(45.654L,-67.66L)
FAIL: gdb.base/callfuncs.exp: p ((int (*) (long double, long double)) t_long_double_values)(45.654,-67.66)
These two tests go through GDB's expression parser for the long double
type. Without the long double fix, GDB is passing 128-bit (amd64
default) but on the MSVC ABI, it should be passing 64-bit.
The other tests pass even without the fix, as those are direct calls
that get the parameter type from DWARF, which has the correct long
double size.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: Ibcc3590753d08ece4fbf03c5d890872197047fff
Pedro Alves [Tue, 14 Jul 2026 18:48:30 +0000 (19:48 +0100)]
gdb.base/callfuncs.exp: Adjust for Windows
On Windows, gdb.base/callfuncs.exp currently ends up skipping the
"noproto" tests, like:
UNTESTED: gdb.base/callfuncs.exp: noproto: failed to prepare
This is because the testcase tries to overwrite the executable while
GDB has the executable still open, which doesn't work on Windows:
Executing on host: x86_64-w64-mingw32-gcc ... -o .../gdb.base/callfuncs/callfuncs
.../x86_64-w64-mingw32/bin/ld.exe: cannot open output file .../gdb.base/callfuncs/callfuncs.exe: Permission denied
Fix this with two changes:
- Compile the prototyped and non-prototyped executables to two
separate executables. This is just what we normally do, so that
it's convenient to test manually against either of the executables.
- Restart GDB instead of just re-running to main, to pick up the new
executable.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I496e0da65f9d484079c5d9a1222104bec39ee98b
.../gdb.base/nodebug.c:63:1: warning: a function definition without a prototype is deprecated in all versions of C and is not supported in C23 [-Wdeprecated-non-prototype]
63 | multf_noproto (v1, v2)
| ^
Fix it by making gdb.base/nodebug.exp disable -Wdeprecated-non-prototype.
Tested with Clang 18.1.3 on x86_64-pc-linux-gnu, and Clang 21.0.0git
on x86_64-pc-windows-msvc.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Id207053331377abec6918aa1188180d609c74273
Tom de Vries [Tue, 21 Jul 2026 20:52:42 +0000 (22:52 +0200)]
[gdb/testsuite] Improve gdb.src/pre-commit.exp
Test-case gdb.src/pre-commit.exp runs all the pre-commit stage hooks, but
produces a single pass:
...
PASS: gdb.src/pre-commit.exp: pre-commit checks
...
Use a dummy run to find all the hooks, and then run them one by one, producing
instead the more informative:
...
PASS: gdb.src/pre-commit.exp: pre-commit: black: run
PASS: gdb.src/pre-commit.exp: pre-commit: flake8: run
PASS: gdb.src/pre-commit.exp: pre-commit: isort: run
PASS: gdb.src/pre-commit.exp: pre-commit: codespell: run
PASS: gdb.src/pre-commit.exp: pre-commit: tclint: run
PASS: gdb.src/pre-commit.exp: pre-commit: check-include-guards: run
PASS: gdb.src/pre-commit.exp: pre-commit: check-whitespace: run
PASS: gdb.src/pre-commit.exp: pre-commit: check-file-mode: run
...
This allows us to get rid of the current SKIP kludge for the pre-commit-setup
hook.
Also skip the gnu-check-style hook, since it only checks patches, not files.
While we're at it, also bail out with unsupported if the pre-commit version is
too old, fixing PR testsuite/33945.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33945
TUI translates ANSI styling sequences to curses color pairs.
Currently, this process uses COLOR_PAIR, which only returns values
from 0 to 255 which results in unexpected reuse of color pairs.
Replacing wattron/wattroff with wcolor_set avoids the 256 color pair
limit imposed by the COLOR_PAIR macro. However, wcolor_set takes a
short for the pair index, limiting pairs to SHRT_MAX.
To support the full range of COLOR_PAIRS (up to 65536 with ncurses
6.1+), init_pair is replaced with init_extended_pair, and the pair
index is passed to wcolor_set via the opts parameter as an extended
color pair, a documented ncurses extension.
This also results in last_color_pair no longer being needed, and so it
is removed.
The extended color pair extension requires ncurses 6.1+, so a
configure check has been added. The fallback path uses the older
color pair API which limits GDB to SHRT_MAX (32767) color pairs.
This patch was tested with make check-gdb TESTS="gdb.tui/*.exp"
Additionally, I tested this with the python extension from the bug
report.
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.
projects / thirdparty / binutils-gdb.git / log
