Tom Tromey [Thu, 23 Jul 2026 15:40:13 +0000 (09:40 -0600)]
Simplify ada_parse_renaming
While working on gnat-llvm, I found that ada_parse_renaming checks the
"loc_class" of the symbol. This caused a problem with my WIP
gnat-llvm patch, which emitted a renaming symbol as LOC_CONST.
I've since fixed my gnat-llvm patch; but nevertheless it seems to me
that there's no need to check this. In Ada, no user-provided symbol
will have an "___XR" substring, as such symbols are all lower-cased.
This patch removes the check, simplifying ada_parse_renaming.
Jan Beulich [Fri, 24 Jul 2026 06:27:34 +0000 (08:27 +0200)]
x86: fold F16C templates with their AVX512VL counterparts
It's not quite clear why this wasn't done so far. These, conceptually,
aren't any different from the FMA ones.
Doing so actually made me notice a flaw in FMA template handling, which is
being fixed alongside making the necessary changes to accommodate F16C:
Both features aren't prereqs of AVX512F. When they're disabled, enabling
AVX512VL would still not allow the 128- and 256-bit forms to assemble.
Jan Beulich [Fri, 24 Jul 2026 06:27:04 +0000 (08:27 +0200)]
x86: correct implied-AVX512VL checking
Templates specifying e.g. AVX2|AVX512F (i.e. providing all of AVX2,
AVX512F, and AVX512VL form(s) at the same time) would presently bypass the
operand size checking in check_VecOperands(). Both t->cpu and t->cpu_any
need taking into account.
While parsing operands, i.types[] is set alongside i.op[].regs->reg_type.
Therefore we can avoid a level of indirection by preferring the former
over the latter when checking operand properties.
Jan Beulich [Fri, 24 Jul 2026 06:23:06 +0000 (08:23 +0200)]
x86: slightly simplify VPBROADCASTQ -> VUNPCKLQDQ optimization again
To fix eb4031cb20aa, c117ca0fc276 ("x86: Check XMM destination when
optimizing 128-bit VPBROADCASTQ") should merely have changed which operand
is checked for being Xmmword. Drop the excess check.
Jan Beulich [Fri, 24 Jul 2026 06:15:18 +0000 (08:15 +0200)]
RISC-V: EEW64 checking
Like the assembler, the disassembler should also use the INSN_V_EEW64
flag. Respectively marked insns shouldn't be disassembled normally when
Zve64x isn't enabled.
While there also drop the redundant Zve32x check from gas: All affected
insns are INSN_CLASS_V, which means Zve32x was already checked to be
enabled (both V and Zve64x imply Zve32x).
Jan Beulich [Fri, 24 Jul 2026 06:14:29 +0000 (08:14 +0200)]
RISC-V: add dedicated vector arithmetic .insn forms
As .insn documentation states, using the available .insn forms can be a
little challenging. For OP_V and OP_VE, help the situation by providing a
few more dedicated forms.
LD/testsuite: Remove $LDFLAGS reference from `run_ld_link_tests'
Fix commit 24602a75d128 ("ld: Append LDFLAGS to flags variable in
default_ld_link") and prevent $LDFLAGS from being included twice in LD
invocations made via `run_ld_link_tests', effectively reverting that
part of commit 740341b9be65 ("Provide dummy libraries for alpha-vms").
testsuite: Also exclude `*-*-kfreebsd*-gnu' from STB_GNU_UNIQUE tests
Fix commit 02e0be69012a ("mbind gas tests and supports_gnu_osabi
testsuite infrastructure") and also match `*-*-kfreebsd*-gnu' targets
when determining whether STB_GNU_UNIQUE binding is supported for
symbols. These targets use the same BFD vectors as `*-*-freebsd*' do,
choosing ELFOSABI_FREEBSD, and therefore need to be treated analogously.
This fixes numerous regressions, e.g.:
mips-kfreebsd-gnu -FAIL: weaken STB_GNU_UNIQUE symbols
mips-kfreebsd-gnu -FAIL: strip on STB_GNU_UNIQUE
mips-kfreebsd-gnu -FAIL: diagnostics for visibility directives
mips-kfreebsd-gnu -FAIL: ld-unique/pr21529
mips-kfreebsd-gnu -FAIL: Linker setting GNU OSABI on STB_GNU_UNIQUE symbol (PR 10549)
caused by the missing feature:
.../gas/testsuite/gas/elf/visibility.s:14: Error: symbol type "gnu_unique_object" is supported only by GNU targets
Andrew Burgess [Sat, 18 Jul 2026 10:37:37 +0000 (11:37 +0100)]
gdb/testsuite: improve rerun scripts generated by make-check-all.sh
The make-check-all.sh script creates little scripts that allow each
board to easily be rerun, useful if a particular test fails and you
want to check a possible fix.
The scripts as currently generated only include the 'make check-...'
line, and are not executable, which means you need to first change to
the correct directory, and invoke the script with 'sh'.
This commit extends the script to include a '#! /bin/sh' line as well
as a 'cd ....' line to switch to the correct directory to run the
test. The script is then made executable.
It should now be easier to rerun tests. There is no change to how
tests are run, or what tests are run with this commit.
Andrew Burgess [Sat, 18 Jul 2026 10:53:46 +0000 (11:53 +0100)]
gdb/testsuite: missing ';' in check-all-boards rule
The check-all-boards makefile rule was missing a semicolon. As a
result we would pass "result=0" through to the make-check-all.sh
script.
This 'result=0' would end up inside the TESTS="..." string which was
passed to the 'make check-...' command. As 'result=0' doesn't match
any of GDB's .exp files the 'result=0' would then be ignored.
Back in the Makefile, due to the missing semicolon, as the
'result=...' line had become an extra argument to make-check-all.sh,
we were no longer capturing the exit status of the make-check-all.sh
script. This means that when the 'check-all-boards' rule completed we
actually exited with the exit status of the last command rather than
with the exit status of the make-check-all.sh script.
Fix this by adding in the missing semicolon.
There should be no changes in what is tested after this commit.
Convert the instance flags of a type to a struct with bitfields. This
helps avoid bitwise operations and instead refer to the fields by
name. In particular, Harvard address space information (i.e. code
space and data space) and address class information become enum values
instead of being handled by seemingly independent bits.
The function make_type_with_address_space is used for creating a type
variant with a particular Harvard address space or an address class
id. The argument is type instance flags. Split the function into
two, each doing one task: (1) making a type variant with a given
Harvard address space id, and (2) making a type variant with a given
address class id. This is a step towards making function signatures
clearer and more descriptive.
Hardcoded shift operations ("<< 2", "<< 4", ">> 4") will go away in a
future patch.
This is yet another refactoring step to treat Harvard address space
ids and address class ids separately and transparently from the fact
that they are stored in type instance flags.
The function 'address_space_name_to_type_instance_flags' converts
address space and address class names to type instance flags. It
deals with the Harvard address space names "code" and "data" as well
as architecture specific address class names. As a result, it may
produce type instance flags where either the Harvard address space
bits or the address class bits are set. The function
'address_space_type_instance_flags_to_name' does the conversion in the
opposite direction.
Inline the functions and remove them. This is a step towards
separating the handling of two concepts.
In type-stack.c, which is used by the parser to convert user inputs
into types, "@code" and "@data" and architecture-specific address
class names are treated the same, too, blurring the difference and
their storage in type instance flags. While we inline the use of
address_space_name_to_type_instance_flags there, we also separate the
two topics by defining different tokens. The patch still pushes type
instance flags into the type stack. The subsequent patch will further
clean this up to store address class and address space ids.
A hardcoded shift operation will go away in a future patch.
Clone the 'insert_into' method of struct type_stack into two
overloads, one taking a type piece and the other taking an integer,
and use the overloads to simplify the 'insert' methods. This is a
refactoring.
gdb: convert address_class_type_flags to address_class_dwarf_to_id
The gdbarch method 'address_class_type_flags' is used for letting an
architecture translate the DW_AT_address_class attribute to an address
class id. Make this clear by refactoring the method to return an id,
instead of a whole type instance flags value. There is hardcoding of
"<< 4" left in dwarf/read.c. This will go away in a future patch.
gdb: convert address_class_name_to_type_flags to address_class_name_to_id
This is the dual of the previous patch, where we refactor the gdbarch
method 'address_class_name_to_type_flags'. We make it take a name and
return an address class id, instead of a whole type instance flags.
In one case, there is hardcoded `aclass << 4` to convert an id to type
instance flags. This will go away in a future patch.
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.
projects / thirdparty / binutils-gdb.git / log
