PowerPC: Fix compile command by reverting to default code model
On ppc64le, the "compile" command produces corrupted code when the
compiled expression takes the address of a symbol in the inferior.
For example:
(gdb) break -qualified main
(gdb) run
(gdb) compile code pmf = &A::get_var1
(gdb) x/2gx &pmf
0x7fffffffeb68: 0x0000800010000d78 0x0000000000000000
The stored address is wrong: the low 32 bits are correct
(0x10000d78, the true address of A::get_var1) but bit 47 is
incorrectly set. When the compiled code later calls through such a
pointer the inferior jumps to unmapped memory and receives SIGSEGV.
Commit 533f04079c7 ("[gdb] [rs6000] Add
ppc64_linux_gcc_target_options method.") made ppc64 return an empty
string from gdbarch_gcc_target_options, overriding the
"-m64 -mcmodel=large" that default_gcc_target_options supplies for
64-bit targets, so GCC uses -mcmodel=medium instead.
With the medium model, references to the inferior's symbols are
compiled as TOC-relative accesses using R_PPC64_TOC16_HA/LO
relocations, whose combined displacement is a signed 32-bit value
(+/- 2GB). GDB allocates the compiled module in the inferior with an
mmap that the kernel places in the high mmap region (e.g. around
0x7ffff7f30000), while the inferior's own text is low (e.g. around
0x10000000). The distance between them is close to 2^47, far beyond
the reach of a TOC16 relocation, so the displacement is silently
truncated to 32 bits, producing an address that is off by 2^47.
Revert 533f04079c7 so that ppc64 again uses
default_gcc_target_options ("-m64 -mcmodel=large"). With the large
model GCC emits a real .toc section and loads addresses as full
64-bit values from it, so the only TOC-relative references are into
the module's own .toc, always in range wherever the module is mapped.
The .TOC. handling from commit bad23de3543 ("[gdb] Handle .TOC.
sections during gdb-compile for rs6000 target.") still applies, now
resolving via the genuine .toc section rather than the .text fallback
the medium model required.
Rohr, Stephan [Tue, 28 Jul 2026 08:01:13 +0000 (10:01 +0200)]
[pre-commit] add 'tomli' dependency for codespell pre-commit hook
The codespell pre-commit hook imports the 'tomllib' module to parse
'pyproject.toml'. 'tomllib' is not available for Python versions 3.10
and older. Add a dependency on 'tomli' so the hook also works on these
Python versions.
MAINTAINERS: Add Maciej W. Rozycki as a global maintainer
By Nick Clifton's appointment and with the endorsement of Alan Modra
I have the privilege to become a global maintainer. Thank you for
the trust put in me.
Andrew Burgess [Thu, 30 Apr 2026 08:29:38 +0000 (09:29 +0100)]
gdb/tui: fix debuginfod prompt using 'C-x C-a' to enter TUI
This commit ties closely into the previous commit. The previous
commit looks at issues that can arise when using 'tui enable' to enter
TUI mode if a debuginfod prompt is triggered. This commit looks at
the problems that can arise when a multi-key combination is used to
enter TUI mode, e.g. 'C-x C-a'. Bug PR gdb/33794 discusses this
issue.
There has been a previous attempt to address this issue here:
The approach taken in that patch was to prevent switching to TUI mode
if debuginfod is still in ASK mode, this means the switch could
potentially trigger a secondary prompt.
While the previous commit is relatively simple, the complexity in this
case arises from how multi-key combinations are handled by readline.
Currently global readline state is used to track the multi-key press
situation, and when the multi-key is dispatched back to application
(GDB) code, the globals are still live.
If GDB then triggers reentry into readline, e.g. by triggering a
secondary prompt, the call into readline for this prompt will cause
the global state to be released. When the secondary prompt is
finished and we return back to readline the global state will be
accessed, and undefined behaviour occurs, including crashes.
The core idea of my proposed solution to this is to move handling of
the multi-key actions out of the readline callback, and into GDB's
normal event loop.
When the user presses a combination like 'C-x C-a' this will call a
templated tui_rl_keybinding function as it currently does, but instead
of immediately forwarding to another function to carry out the TUI
changes, we instead schedule a callback with the event loop and then
return.
As far as readline is concerned the multi-key action has now been
dealt with, however, no interface changes have yet occurred. As
readline has now finished handling this key press, readline returns to
the event loop to get the next user input.
At the event loop the pending callback is seen and dispatched. This
callback triggers the actual UI changes, e.g. entering TUI mode. As
we are not inside readline at this point we are free to create
secondary prompts if needed.
In tui_rl_keybinding we use run_on_main_thread to schedule a callback
with the event loop, but there are some additional changes needed:
1. If we changed the tui_active state then we need to call
reinitialize_more_filter. Previously tui_rl_switch_mode would call
rl_newline which would make readline think that a command had been
fully entered, this would trigger a call to GDB's
command_line_handler, which calls command_handler, which then calls
reinitialize_more_filter.
For reasons explained below tui_rl_switch_mode can no longer call
rl_newline, so the reinitialize_more_filter is never reached. This
means that especially when switching CLI to TUI, when the `cmd`
window is smaller than the CLI terminal, GDB might enter TUI mode
thinking that the TUI is already full. This leads to incorrect
pager prompts appearing. Resolve this by explicitly resetting the
pager.
2. After changing the tui_active state (i.e. entering or leaving TUI
mode), there will not be a GDB prompt displayed. Under the old
scheme, the rl_newline call in tui_rl_switch_mode would trick GDB
into thinking an empty command had just been completed, this would
then trigger a prompt redisplay.
Under the new scheme we need to explicitly call display_gdb_prompt
or tui_redisplay_readline to redraw the prompt. However, as we
were at a GDB prompt already when the user pressed a key like 'C-x
C-a', the current_ui will not think that a prompt is needed, if we
plan to call display_gdb_prompt then we'll need to change the
prompt_state to PROMPT_NEEDED before calling display_gdb_prompt.
When possible we prefer calling tui_redisplay_readline, as this
preserves the current readline input line buffer contents, so if
the user types something at the prompt and then does 'C-x o' to
change window focus, the partially typed text is preserved.
Both of these additional actions need to be performed for both the
normal exit path, and the exception path in order that the prompt be
correctly displayed, so this code is done in a SCOPE_EXIT block.
The other set of changes are in tui_rl_switch_mode:
1. The calls to rl_prep_terminal are no longer needed as
display_gdb_prompt will take care of calling this for us if
appropriate (e.g. we are not in TUI mode).
2. The gdb_exception_forced_quit handling can now just propagate the
exception, We are no longer within a readline callback, and so can
throw this exception further up the stack.
3. Likewise with gdb_exception, we can re-throw this. As the
run_on_main_thread mechanism silently swallows all gdb_exceptions
except the gdb_exception_forced_quit sub-class, we do need to print
the exception ourselves first though. This is why we had to
separate out the gdb_exception_forced_quit handling.
4. The rl_kill_text call is no longer needed as the following
rl_newline call is going to be removed.
5. The rl_newline call was a neat trick to force a prompt redisplay,
but this only works when we are within a readline callback, it
injects a newline so that when we return from this callback
readline will see the pending newline character, process the now
empty line (thanks to the rl_kill_text call), and the print the
prompt. This is replaced by the display_gdb_prompt call that was
added to tui_rl_keybinding.
6. The dont_repeat call was needed because the rl_kill_text and
rl_newline calls were tricking readline into thinking the user had
pressed Enter on an empty line, this was done to force a prompt
redisplay.
However, pressing Enter on an empty line repeats the previous
command unless dont_repeat has been called. Now we don't use the
rl_newline trick, the dont_repeat call is not needed.
The gdb.tui/debuginfod-query.exp test is updated to include tests that
switch using multi-key combinations.
Andrew Burgess [Tue, 28 Apr 2026 06:40:11 +0000 (07:40 +0100)]
gdb/tui: fix for debuginfod prompt while enabling the TUI
PR tui/31449 reports a SIGFPE when the debuginfod query happens while
enabling TUI using the "tui enable" command:
Thread 1 "gdb" received signal SIGFPE, Arithmetic exception.
0x0000000001021084 in tui_inject_newline_into_command_window () at /data/vries/gdb/src/gdb/tui/tui-io.c:1096
1096 py += px / tui_cmd_win ()->width;
due to divide-by-zero because tui_cmd_win ()->width == 0.
The corresponding backtrace is:
(gdb) bt
#0 0x0000000001021084 in tui_inject_newline_into_command_window () at gdb/tui/tui-io.c:1096
#1 0x0000000000fe65fd in gdb_readline_wrapper_line (line=...) at gdb/top.c:939
#2 0x0000000000944eef in gdb_rl_callback_handler (rl=0x2cc865a0 "n") at gdb/event-top.c:288
#3 0x0000000001175779 in rl_callback_read_char () at readline/readline/callback.c:302
#4 0x0000000000944bc3 in gdb_rl_callback_read_char_wrapper_sjlj () at gdb/event-top.c:197
#5 0x0000000000944cd4 in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:240
#6 0x0000000000944d52 in gdb_rl_callback_read_char_wrapper (...) at gdb/event-top.c:252
#7 0x0000000001062352 in stdin_event_handler (error=0, client_data=0x2c865150) at gdb/ui.c:154
#8 0x0000000001a04edf in handle_file_event (file_ptr=0x2ccf8850, ready_mask=1) at gdbsupport/event-loop.cc:551
#9 0x0000000001a05522 in gdb_wait_for_event (block=1) at gdbsupport/event-loop.cc:672
#10 0x0000000001a043ff in gdb_do_one_event (mstimeout=-1) at gdbsupport/event-loop.cc:263
#11 0x00000000006d5480 in interp::do_one_event (this=0x2cc2af20, mstimeout=-1) at gdb/interps.h:93
#12 0x0000000000fe670d in gdb_readline_wrapper (prompt=0x2ccca4e0 "Enable debuginfod for this session? (y or [n]) ") at gdb/top.c:1033
#13 0x00000000010c6853 in defaulted_query(...) (...) at gdb/utils.c:844
#14 0x00000000010c6b8a in nquery (...) at gdb/utils.c:901
#15 0x00000000007a9324 in debuginfod_is_enabled () at gdb/debuginfod-support.c:268
#16 0x00000000007a950d in debuginfod_source_query (...) at gdb/debuginfod-support.c:311
#17 0x0000000000efc2c7 in open_source_file (s=0x2cc8f4b0) at gdb/source.c:1152
#18 0x0000000000efc619 in symtab_to_fullname (...) at gdb/source.c:1214
#19 0x0000000000f5ebb3 in find_line_symtab (...) at gdb/symtab.c:3287
#20 0x0000000000f5f0e5 in find_pc_for_line (...) at gdb/symtab.c:3391
#21 0x0000000001011f54 in tui_get_begin_asm_address (...) at gdb/tui/tui-disasm.c:404
#22 0x000000000104888d in tui_source_window_base::rerender (this=0x2cbdc570) at gdb/tui/tui-winsource.c:474
#23 0x0000000001028e81 in tui_win_info::resize (this=0x2cbdc570, height_=21, width_=127, origin_x_=0, origin_y_=0) at gdb/tui/tui-layout.c:299
#24 0x00000000010297d0 in tui_layout_window::apply (this=0x2cc50350, x_=0, y_=0, width_=127, height_=21, preserve_cmd_win_size_p=false) at gdb/tui/tui-layout.c:432
#25 0x000000000102bfea in tui_layout_split::apply (this=0x2caea920, x_=0, y_=0, width_=127, height_=33, preserve_cmd_win_size_p=false) at gdb/tui/tui-layout.c:1026
#26 0x0000000001028267 in tui_apply_current_layout (...) at gdb/tui/tui-layout.c:68
#27 0x0000000001028737 in tui_set_layout (layout=0x2c9b9e90) at gdb/tui/tui-layout.c:133
#28 0x0000000001028af5 in tui_set_initial_layout () at gdb/tui/tui-layout.c:209
#29 0x000000000104b795 in tui_enable () at gdb/tui/tui.c:496
#30 0x000000000104bab3 in tui_enable_command (args=0x0, from_tty=1) at gdb/tui/tui.c:591
#31 0x00000000006c5ffe in do_simple_func (args=0x0, from_tty=1, c=0x2c9bb2f0) at gdb/cli/cli-decode.c:94
#32 0x00000000006cc94f in cmd_func (cmd=0x2c9bb2f0, args=0x0, from_tty=1) at gdb/cli/cli-decode.c:2831
#33 0x0000000000fe53ad in execute_command (p=0x2c86699a "", from_tty=1) at gdb/top.c:563
#34 0x000000000094584d in command_handler (command=0x2c866990 "tui enable") at gdb/event-top.c:611
#35 0x0000000000945dfe in command_line_handler (rl=...) at gdb/event-top.c:844
#36 0x000000000101e916 in tui_command_line_handler (rl=...) at gdb/tui/tui-interp.c:101
#37 0x0000000000944eef in gdb_rl_callback_handler (rl=0x2cc86a30 "tui enable") at gdb/event-top.c:288
#38 0x0000000001175779 in rl_callback_read_char () at readline/readline/callback.c:302
#39 0x0000000000944bc3 in gdb_rl_callback_read_char_wrapper_sjlj () at gdb/event-top.c:197
#40 0x0000000000944cd4 in gdb_rl_callback_read_char_wrapper_noexcept () at gdb/event-top.c:240
#41 0x0000000000944d52 in gdb_rl_callback_read_char_wrapper (...) at gdb/event-top.c:252
#42 0x0000000001062352 in stdin_event_handler (error=0, client_data=0x2c865150) at gdb/ui.c:154
#43 0x0000000001a04edf in handle_file_event (file_ptr=0x2ccf8850, ready_mask=1) at gdbsupport/event-loop.cc:551
#44 0x0000000001a05522 in gdb_wait_for_event (block=1) at gdbsupport/event-loop.cc:672
#45 0x0000000001a043ff in gdb_do_one_event (mstimeout=-1) at gdbsupport/event-loop.cc:263
#46 0x00000000006d5480 in interp::do_one_event (this=0x2cc2af20, mstimeout=-1) at gdb/interps.h:93
#47 0x0000000000b77f25 in start_event_loop () at gdb/main.c:403
#48 0x0000000000b78113 in captured_command_loop () at gdb/main.c:468
#49 0x0000000000b7a07c in captured_main (context=0x7fff660b9e60) at gdb/main.c:1381
#50 0x0000000000b7a178 in gdb_main (args=0x7fff660b9e60) at gdb/main.c:1400
#51 0x0000000000419705 in main (argc=5, argv=0x7fff660b9f98) at gdb/gdb.c:38
(gdb)
The problem is that while the TUI is being enabled for the first time,
none of the TUI windows yet exist. As each window is created its
contents are rendered (i.e. filled in based on GDB's state), which for
some windows can trigger an interactive prompt, in this case a missing
source file triggers a debuginfod prompt while trying to render the
`src` window.
The interactive prompt will be written to the `cmd` window, but at
this point the `cmd` window has not yet been created.
There have been several different attempts to fix this issue:
The patch presented here is similar to what was presented in (3)
above, but I think the implementation is maybe a little simpler.
Additionally, all but (6) of the above patches don't address issues
related to using multi-key combinations like 'C-x C-a' to enable TUI
mode, and that patch just takes the (admittedly safe) approach of
preventing the user from activating the TUI using a multi-key
combination if debuginfod is in ASK mode (and so could trigger an
interactive prompt).
This patch doesn't address the multi-key problem, that is left for the
next patch in this series.
This patch ensures that the `cmd` window always exists before
rendering the windows (i.e. filling in their content). This is done
by introducing a tui_defer_rerender global which is set in tui_enable,
and checked in tui_win_info::resize. Then, prior to the prompt being
displayed, if the flag is set, we render the contents of all visible
windows. This can trigger a secondary prompt (e.g. the debuginfod
prompt), but by this point the `cmd` window exists, and can display
the prompt.
The debuginfod-query.exp test included here is based on the test Tom
de Vries wrote for one of his patches listed above, but extended to
cover some additional cases. The activate-with-key-combo.exp test is
new for this series.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31449 Co-Authored-By: Tom de Vries <tdevries@suse.de>
Andrew Burgess [Tue, 28 Apr 2026 10:06:48 +0000 (11:06 +0100)]
gdb/tui: prevent TUI activation from a secondary prompt
The TUI can be activated with key combinations like 'C-x C-a'. This
is handled by readline calling the function tui_rl_switch_mode, or
various other functions which indirectly call that function.
These multi-key combinations can be used even at a secondary prompt,
e.g. the:
Make breakpoint pending on future shared library load? (y or [n])
The problem with this is that when the TUI activates CLI content
doesn't carry over into the `cmd` window, so the secondary prompt is
not visible to the user after the mode switch. Worse, because the
content doesn't carry over we clear the readline state, and this
involves sending a '\n' to readline. This newline will select the
default action at the secondary prompt, which might not be what the
user actually wants.
Now, we could imagine trying to "fix" this so that the CLI content is
copied over into the `cmd` window, and the secondary prompt is
represented to the user, so they can then make the choice they want,
but implementing this fix would be a big job, for very little gain.
I think it is easier to just prevent the user switching to TUI mode
while at a secondary prompt.
I created a new templated wrapper function tui_rl_keybinding, which is
then used to wrap every function that is bound to a readline multi-key
combination. The wrapper function checks if we are in a secondary
prompt, and if we are, performs an early return.
For completeness, I've added an assert that we are not in a secondary
prompt to all of the wrapped functions, this (hopefully) will help
catch cases where these functions are called directly without going
through the wrapper. I also added the same assert to
tui_rl_command_key and tui_rl_command_mode which are not themselves
wrapped functions, but are only used when in single key mode, and it
is not possible to enter single key mode when at a separate prompt,
see tui_rl_startup_hook (which checks for being at a secondary prompt)
and tui_rl_next_keymap (which is wrapped).
There's a new helper proc added to lib/gdb.exp, this will be used by
additional tests later in this series.
The user can still switch to TUI mode at the primary '(gdb)' prompt.
Andrew Burgess [Tue, 28 Apr 2026 12:59:22 +0000 (13:59 +0100)]
gdb/testsuite: fix tuiterm linefeed scrolling new line content
I came across a bug in the implementation of line feed in tuiterm.
Consider the gdb.tui/tuiterm.exp test 'test_linefeed_scroll', before
sending the line feed we have:
Notice that the new line #3 retains its previous contents, all lines
have scrolled up, with the old line #0 having been moved off the
terminal, but the new line is starting with these cloned contents.
I don't believe this is correct. My understanding is that new lines
should be created empty -- or really full of space characters.
After fixing this issue so that new lines are created empty, the only
test failure is the tuiterm.exp unit test mentioned above, this was
added in commit:
This commit is fixing an issue with cursor placement after a scroll,
there is no mention of the content of the new line, which makes me
think that the test is just checking whatever behaviour used to be
there.
In this commit I think we should fix the new line content, and update
the existing unit test to match the new behaviour.
Andrew Burgess [Mon, 27 Apr 2026 20:18:56 +0000 (21:18 +0100)]
gdb/tui: convert a window handle `if` into an `assert`
It should only be possible to call tui_win_info::refresh_window on a
window with a valid handle member. To do otherwise would suggest
we're trying to draw to the screen a window which GDB doesn't think is
part of the current layout, which is just wrong.
Currently tui_win_info::refresh_window guards its content with an
`if (handle != NULL)`, but this can be changed to an assert.
A similar assert can be added to
tui_source_window_base::refresh_window, there's no `if` in this
function, which only backs up the reasoning in the first paragraph.
There should be no user-visible changes after this commit.
gdb.rocm/watchpoint-basic: add XFAILs for known configurations
Some of the tests in gdb.rom/watchpoint-basic are destined to fail
due to a problem in KFD. This patch marks those tests as such on
configurations that this can happen.
Reviewed-by: Tankut Baris Aktemur <tankutbaris.aktemur@amd.com> Approved-by: Luis Machado <luis.machado.foss@gmail.com>
Jan Beulich [Mon, 27 Jul 2026 07:14:57 +0000 (09:14 +0200)]
aarch64: remove casts from more struct initializers
Commit 0e89ce812b79 ("aarch64: Remove cast from struct initializer")
didn't go quite far enough: The building of aarch64-gen itself has a
similar issue. Cover that as well. Since FLD_CONST_* are used only there,
move their #define-s there rather than introducing more #undef-s.
Alan Modra [Mon, 27 Jul 2026 05:28:50 +0000 (14:58 +0930)]
Use ufile_ptr for file position
This is in response to a fuzzed objcopy test that overflows file_ptr
addition. It makes sense to use an unsigned value for current file
offset, and allows a couple of casts to be removed.
* elf.c (assign_file_positions_for_load_sections): Make off unsigned.
(assign_file_positions_except_relocs): Likewise.
(_bfd_elf_assign_file_positions_for_non_load): Likewise.
Alan Modra [Mon, 27 Jul 2026 01:57:45 +0000 (11:27 +0930)]
DWARF1 AT_sibling sanity check
I am not absolutely certain that DWARF version 1 AT_sibling always
points forward, but that seems to be the case for gcc-3.3 from a quick
look at gcc/dwarfout.c and examining some i686-linux output. I
believe gcc stopped supporting DWARF version 1 after gcc-3.3.
If backward links are allowed then it is considerably more tedious to
protect against fuzzed object files that loop forever reading DWARF1.
So this patch may break addr2line and objdump -dS for some old files.
If it does, well, removing DWARF1 support entirely would break that
support too. (readelf doesn't support DWARF version 1).
* dwarf1.c (parse_die): Replace abfd and aDiePtrEnd parameters
with stash pointer. Adjust to suit. Sanity check AT_sibling
value.
(parse_functions_in_unit, _bfd_dwarf1_find_nearest_line): Adjust
parse_die calls.
Alan Modra [Sat, 25 Jul 2026 01:04:09 +0000 (10:34 +0930)]
Make use of coff internal_reloc r_ignore
Set r_ignore on relocs already handled by a backend relocate_section,
rather than choosing a "do nothing" r_type. This avoids bugs in all
three targets with in_reloc_p, which resulted in addresses being
emitted for dynamic relocs at all of these "do nothing" relocs.
* coff-aarch64.c (coff_pe_aarch64_relocate_section): Leave r_type
unchanged on relocs handled here. Set r_ignore instead.
* coff-i386.c (coff_pe_i386_relocate_section): Likewise.
* coff-x86_64.c (coff_pe_amd64_relocate_section): Likewise.
Cosmetic fix in r_type handled here. Formatting.
Tom de Vries [Sat, 25 Jul 2026 06:59:51 +0000 (08:59 +0200)]
[gdb/testsuite] Fix race in gdb.threads/leader-exit.exp
On aarch64-linux, when running test-case gdb.threads/leader-exit.exp with
"taskset -c 0", 3 out of 10 times I run into:
...
(gdb) continue
Continuing.
[New Thread 0xfffff7d1f160 (LWP 62010) (id 2)]
[Switching to thread 2 (Thread 0xfffff7d1f160 (LWP 62010))]
Thread 2 "leader-exit" hit Breakpoint 2, start (arg=0x0) at leader-exit.c:32
32 sleep (10); /* break-here */
(gdb) PASS: gdb.threads/leader-exit.exp: continue to breakpoint: break-here
info threads
Id Target Id Frame
1 Thread 0xfffff7fe8020 (LWP 62008) "leader-exit" (Exiting) \
0x0000fffff7d46fa0 in __libc_start_call_main () from /lib64/libc.so.6
* 2 Thread 0xfffff7d1f160 (LWP 62010) "leader-exit" \
start (arg=0x0) at leader-exit.c:32
(gdb) FAIL: gdb.threads/leader-exit.exp: single thread has been left
...
In a passing version, the continue produces a "Thread exited" message, but
that's missing here.
The problem is that after the pthread_join is executed:
...
i = pthread_join (main_thread, NULL);
...
sleep (10); /* break-here */
...
there's a race between:
- the breakpoint at break-here triggering, and
- the "Thread exited" message for the main thread being reported.
Fix this by:
- adding a loop before the break location
- waiting in the loop until the "Thread exited" message is seen
- sending ^C to get a prompt
- setting a variable to exit the loop
Likewise in gdb.threads/non-ldr-exc-2.exp.
Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34425
Tom de Vries [Sat, 25 Jul 2026 06:29:16 +0000 (08:29 +0200)]
[gdb/testsuite] Fix timeout in gdb.threads/vfork-multi-inferior.exp
With test-case gdb.threads/vfork-multi-inferior.exp I get either:
...
(gdb) run &
Starting program: vfork-multi-inferior-sleep
(gdb) PASS: $exp: method=non-stop: run inferior 2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) PASS: $exp: method=non-stop: inferior 1
...
or:
...
(gdb) run &
Starting program: vfork-multi-inferior-sleep
(gdb) PASS: $exp: method=non-stop: run inferior 2
inferior 1^M
[Switching to inferior 1 [<null>] (<noexec>)]^M
(gdb) PASS: $exp: method=non-stop: inferior 1
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
...
With a 16.3-based package on aarch64-linux, I ran into:
...
(gdb) run &
Starting program: vfork-multi-inferior-sleep
(gdb) PASS: $exp: method=non-stop: run inferior 2
inferior 1
[Switching to inferior 1 [<null>] (<noexec>)]
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
FAIL: $exp: method=non-stop: inferior 1
(timeout)
...
Unfortunately I have not been able to reproduce this.
Fix this using -no-prompt-anchor.
See also commit 5f69c00a6e0 ("[gdb/testsuite] Fix timeout in
gdb.base/async-shell.exp").
Reviewed-By: Keith Seitz <keiths@redhat.com> Approved-By: Kevin Buettner <kevinb@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34427
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:
projects / thirdparty / binutils-gdb.git / log
