Tom Tromey [Thu, 15 Feb 2024 20:14:43 +0000 (13:14 -0700)]
Rewrite "python" command exception handling
The "python" command (and the Python implementation of the gdb
"source" command) does not handle Python exceptions in the same way as
other gdb-facing Python code. In particular, exceptions are turned
into a generic error rather than being routed through
gdbpy_handle_exception, which takes care of converting to 'quit' as
appropriate.
I think this was done this way because PyRun_SimpleFile and friends do
not propagate the Python exception -- they simply indicate that one
occurred.
This patch reimplements these functions to respect the general gdb
convention here. As a bonus, some Windows-specific code can be
removed, as can the _execute_file function.
The bulk of this change is tweaking the test suite to match the new
way that exceptions are displayed. These changes are largely
uninteresting. However, it's worth pointing out the py-error.exp
change. Here, the failure changes because the test changes the host
charset to something that isn't supported by Python. This then
results in a weird error in the new setup.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 Acked-By: Tom de Vries <tdevries@suse.de> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom Tromey [Thu, 15 Feb 2024 19:12:25 +0000 (12:12 -0700)]
Introduce read_remainder_of_file
This patch adds a new function, read_remainder_of_file. This is like
read_text_file_to_string, but reads from an existing 'FILE *'. This
will be used in a subsequent patch.
Tom de Vries [Tue, 27 Feb 2024 15:24:15 +0000 (16:24 +0100)]
[gdb/testsuite] Reset errcnt and warncnt in default_gdb_init
Say we do:
...
$ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp"
...
and add a perror at the end of pause.exp:
...
dap_shutdown
+
+perror "foo"
...
We run into:
...
UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb
...
This happens because the perror increases the errcnt, which is not reset at
the end of the test-case, and consequently the first pass in the following
test-case is changed into an unresolved.
Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the
end of the test-case, which does reset the errcnt, but this is with version
1.6.1.
Furthermore, we reset the errcnt in clean_restart, but the pass is produced
before, so that doesn't help either.
Fix this by resetting errcnt and warncnt in default_gdb_init.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31351
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351
Tom de Vries [Tue, 27 Feb 2024 15:18:32 +0000 (16:18 +0100)]
[gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp
With test-case gdb.python/py-finish-breakpoint.exp, we run into:
...
(gdb) python print (finishbp_default.hit_count)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Breakpoint 3 is invalid.
Error while executing Python code.
(gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \
check finishBP on default frame has been hit
...
The test producing the pass is:
...
gdb_test "python print (finishbp_default.hit_count)" "1.*" \
"check finishBP on default frame has been hit"
...
so the pass is produced because the 1 in "line 1" matches "1.*".
Temporary breakpoints are removed when hit, and consequently accessing the
hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is
not possible, and as per spec we get a RuntimeError.
So the RuntimeError is correct, and not specific to finish breakpoints.
The test presumably attempts to match:
...
(gdb) python print (finishbp_default.hit_count)
1
...
but most likely this output was never produced by any gdb version.
Fix this by checking whether the finishbp_default breakpoint has hit by
checking that finishbp_default.is_valid() is False.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31391
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391
Pedro Alves [Thu, 6 May 2021 19:59:14 +0000 (20:59 +0100)]
Cygwin: Fix putting inferior in foreground (fix input)
gdb.base/interrupt.exp reveals that inferior input is
broken on Cygwin:
(gdb) continue
Continuing.
talk to me baby
Input/output error <<< BAD
PASS: gdb.base/interrupt.exp: process is alive
a
[Thread 10688.0x2590 exited with code 1]
[Thread 10688.0x248c exited with code 1]
[Thread 10688.0x930 exited with code 1]
[Thread 10688.0x2c98 exited with code 1]
Program terminated with signal SIGHUP, Hangup.
The program no longer exists.
(gdb) FAIL: gdb.base/interrupt.exp: child process ate our char
a
Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior...
(gdb) ERROR: "" is not a unique command name.
The problem is that inflow.c:child_terminal_inferior is failing to put
the inferior in the foreground, because we're passing down the
inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp.
That is fixed by this commit. Afterwards we will get:
(gdb) continue
Continuing.
talk to me baby
PASS: gdb.base/interrupt.exp: process is alive
a
a <<< GOOD
PASS: gdb.base/interrupt.exp: child process ate our char
[New Thread 7236.0x1c58]
Thread 6 received signal SIGINT, Interrupt. <<< new thread spawned for SIGINT
[Switching to Thread 7236.0x1c58]
0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
(gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C
We still have the FAIL seen above because this change has another
consequence. By failing to put the inferior in the foreground
correctly, Ctrl-C was always reaching GDB first. Now that the
inferior is put in the foreground properly, Ctrl-C reaches the
inferior first, which results in a Windows Ctrl-C event, which results
in Windows injecting a new thread in the inferior to report the Ctrl-C
exception => SIGINT. That is, running the test manually:
Before patch:
(gdb) c
Continuing.
[New Thread 2352.0x1f5c]
[New Thread 2352.0x1988]
[New Thread 2352.0x18cc]
<<< Ctrl-C pressed.
Thread 7 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 2352.0x18cc]
0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb)
Above, GDB got the SIGINT, and it manually passes it down the
inferior, which reaches windows_nat_target::interrupt(), which
interrupts the inferior with DebugBreakProcess (which injects a new
thread in the inferior that executes an int3 instruction).
After this patch, we have (with "set debugexceptions on" so
DBG_CONTROL_C is visible):
(gdb) c
Continuing.
[New Thread 9940.0x1168]
[New Thread 9940.0x5f8]
gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
[New Thread 9940.0x3d8]
gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b <<< Ctrl-C
Thread 7 received signal SIGINT, Interrupt. <<< new injected thread
[Switching to Thread 9940.0x3d8]
0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
(gdb)
This new behavior is exactly the same as what you see with a MinGW GDB
build. Also, SIGINT reaching inferior first is what you get on Linux
as well currently.
I wrote an initial fix for this before I discovered that Cygwin
downstream had a similar change, so I then combined the patches. I am
adding a Co-Authored-By for that reason.
Co-Authored-By: Takashi Yano <takashi.yano@nifty.ne.jp> Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f
Yuriy Kolerov [Thu, 22 Feb 2024 08:02:19 +0000 (08:02 +0000)]
arc: Don't build arc-analyze-prologue.S with -g
arc-analyze-prologue.S test does not contain debug information thus
it must be compiled without -g option. Otherwise GDB will try to
unwind frames using debug information (which does not exist for .S
code!) instead of analyzing frames manually.
Andreas Krebbel [Tue, 27 Feb 2024 13:01:41 +0000 (14:01 +0100)]
s390: Avoid reloc overflows on undefined weak symbols
Replace relative long addressing instructions of weak symbols, which
will definitely resolve to zero, with either a load address of 0, a
NOP, or a trapping insn.
This prevents the PC32DBL relocation from overflowing in case the
binary will be loaded at 4GB or more.
bfd/ChangeLog:
* bfd/elf64-s390.c (elf_s390_relocate_section): Replace
instructions using undefined weak symbols with relative addressing
to avoid relocation overflows.
ld/ChangeLog:
* ld/testsuite/ld-s390/s390.exp:
* ld/testsuite/ld-s390/8GB.ld: New test.
* ld/testsuite/ld-s390/weakundef-1.dd: New test.
* ld/testsuite/ld-s390/weakundef-1.s: New test.
Matthieu Longo [Fri, 23 Feb 2024 14:52:58 +0000 (14:52 +0000)]
aarch64: rename internals related to PAuth feature to use pauth in their naming for coherency
Hi,
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion.
Regression tested on aarch64-none-elf, and no regression found.
Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf.
Regards,
Matthieu.
From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001
From: Matthieu Longo <matthieu.longo@arm.com>
Date: Fri, 23 Feb 2024 11:30:40 +0000
Subject: [PATCH] aarch64: rename internals related to PAuth feature to use
pauth in their naming for coherency
Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature
with internal names that don't match the actual feature name pauth. The new
feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature
of Armv8.3-A. Using a different naming for it not based on the formerly "PAC"
would create confusion.
Jinyang He [Tue, 5 Sep 2023 02:31:28 +0000 (10:31 +0800)]
LoongArch: ld: Fix other pop relocs overflow check and add tests
Add reloc_unsign_bits() to fix others sop_pop relocs overflow check.
Then add over/underflow tests for relocs B*, SOP_POP* and PCREL20_S2.
bfd/ChangeLog:
* bfd/elfxx-loongarch.c: Add reloc_unsign_bits().
ld/ChangeLog:
* ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add tests.
* ld/testsuite/ld-loongarch-elf/abi1_max_imm.dd: New test.
* ld/testsuite/ld-loongarch-elf/abi1_max_imm.s: New test.
* ld/testsuite/ld-loongarch-elf/abi1_sops.s: New test.
* ld/testsuite/ld-loongarch-elf/abi2_max_imm.s: New test.
* ld/testsuite/ld-loongarch-elf/abi2_overflows.s: New test.
* ld/testsuite/ld-loongarch-elf/max_imm_b16.d: New test.
* ld/testsuite/ld-loongarch-elf/max_imm_b21.d: New test.
* ld/testsuite/ld-loongarch-elf/max_imm_b26.d: New test.
* ld/testsuite/ld-loongarch-elf/max_imm_pcrel20.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_b16.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_b21.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_b26.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_pcrel20.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_0_10_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_0_5_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_10_12.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_10_16.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_10_5.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_s_5_20.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_u.d: New test.
* ld/testsuite/ld-loongarch-elf/overflow_u_10_12.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_b16.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_b21.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_b26.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_pcrel20.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_0_10_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_0_5_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_10_12.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_10_16.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_10_16_s2.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_10_5.d: New test.
* ld/testsuite/ld-loongarch-elf/underflow_s_5_20.d: New test.
mengqinggang [Thu, 22 Feb 2024 12:18:25 +0000 (20:18 +0800)]
LoongArch: bfd: Fix some bugs of howto table
R_LARCH_IRELATIVE: For dynamic relocation that does not distinguish between
32/64 bits, size and bitsize set to 8 and 64.
R_LARCH_TLS_DESC64: Change size to 8.
R_LARCH_SOP_POP_32_S_0_5_10_16_S2: Change src_mask to 0, dst_mask to
0x03fffc1f.
Tom Tromey [Mon, 26 Feb 2024 20:50:54 +0000 (13:50 -0700)]
Remove two unnecessary casts
I noticed a spot in ada-lang.c where the return value of
value_as_address was cast to CORE_ADDR -- a no-op cast. I searched
and found another. This patch fixes both.
Pedro Alves [Wed, 21 Feb 2024 16:23:55 +0000 (16:23 +0000)]
[gdb] Fix heap-use-after-free in select_event_lwp
PR gdb/31259 reveals one scenario where we run into a
heap-use-after-free reported by thread sanitizer, while running
gdb.base/vfork-follow-parent.exp.
The heap-use-after-free happens during the following scenario:
- linux_nat_wait_1 is about to return an event for T2. It stops all
other threads, and while doing so, stop_wait_callback -> wait_lwp
sees T1 exit, and decides to leave the exit event pending. It
should have set the lp->stopped flag too, but does not -- this is
the bug.
- The event for T2 is reported, is processed by infrun, and we're
back at linux_nat_wait_1.
- linux_nat_wait_1 selects LWP T1 with the pending exit status to
report.
- it sets variable lp to point to the corresponding lwp_info.
- it calls stop_callback and stop_wait_callback for all threads
(because !target_is_non_stop_p ()).
- it calls select_event_lwp to maybe pick another thread than T1, to
prevent starvation.
The problem is the following:
- while calling stop_wait_callback for all threads, it also does this
for T1. While doing so, the corresponding lwp_info is deleted
(callstack stop_wait_callback -> wait_lwp -> exit_lwp ->
delete_lwp), leaving variable lp as a dangling pointer.
- variable lp is passed to select_event_lwp, which derefences it,
which causes the heap-use-after-free.
Note that the comment here mentions "all other LWP's":
...
/* Now stop all other LWP's ... */
iterate_over_lwps (minus_one_ptid, stop_callback);
/* ... and wait until all of them have reported back that
they're no longer running. */
iterate_over_lwps (minus_one_ptid, stop_wait_callback);
...
The reason the comments say "all other LWP's", and doesn't bother
filtering out LP is that lp->stopped should be true at this point, and
the callbacks (both stop_callback and stop_wait_callback) check that
flag, and do nothing if set. I.e., they skip already-stopped threads,
so they should skip LP.
In this particular scenario, though, we missed setting the stopped
flag right in the first step described above, so LP was iterated over
incorrectly.
The fix is to make wait_lwp set the lp->stopped flag when it decides
to leave the exit event pending. However, going a bit further,
gdbserver has a mark_lwp_dead function to centralize setting up
various lwp flags such that the rest of the code doesn't mishandle
them, and it seems like a good idea to do a similar thing in gdb as
well. That is what this patch does.
PR gdb/31259
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31259 Co-Authored-By: Tom de Vries <tdevries@suse.de>
Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9
Tom de Vries [Mon, 26 Feb 2024 15:03:45 +0000 (16:03 +0100)]
[gdb/testsuite] Dump dap.log.$n to gdb.log when exceptions found
For a patch I submitted, the Linaro CI reported a failure:
...
FAIL: gdb.dap/attach.exp: exceptions in log file
...
I ran the test-case locally, and observed the same FAIL in the gdb.sum file.
I then wanted to confirm that I reproduced the exact same problem, but
realized that I couldn't because there's no way for me to know what exception
occurred, and where, because that information is logged in the dap.log.$n
file, and the Linaro CI only saves the gdb.sum and gdb.log files.
This issue is even worse if only the CI can reproduce a FAIL.
Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when
exceptions are found.
Tom de Vries [Mon, 26 Feb 2024 14:59:47 +0000 (15:59 +0100)]
[gdb/testsuite] Further handle long filenames in gdb.base/startup-with-shell.exp
In commit 52498004a34 ("gdb/testsuite: handle long filenames in
gdb.base/startup-with-shell.exp") we fixed a FAIL reported by the Linaro CI:
...
(gdb) print argv[1]
$1 = 0xfffed978 "<snip>/startup-with-shell/unique-file.unique-e"...
(gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; \
run_args = *.unique-extension: first argument expanded
...
PR testsuite/31410 reports a similar failure:
...
(gdb) print argv[1]
$1 = 0xfffeda96 "<snip>/startup-with-shell/*.unique-extens"...
(gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = off; \
run_args = *.unique-extension: first argument not expanded
...
Fix this in the same way, using "set print characters unlimited".
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410
Tom de Vries [Mon, 26 Feb 2024 14:31:34 +0000 (15:31 +0100)]
[gdb] Fix "value is not available" with debug frame
On arm-linux, with a started hello world, running "info frame" works fine, but
when I set debug frame to on, I run into:
...
(gdb) info frame
...
[frame] frame_unwind_register_value: exit
value is not available
(gdb)
...
The problem is here in frame_unwind_register_value:
...
if (value->lazy ())
gdb_printf (&debug_file, " lazy");
else
{
int i;
gdb::array_view<const gdb_byte> buf = value->contents ();
...
where we call value->contents () while !value->entirely_available ().
Fix this by checking value->entirely_available () and printing:
...
[frame] frame_unwind_register_value: -> register=91 unavailable
...
Tiezhu Yang [Thu, 22 Feb 2024 07:29:11 +0000 (15:29 +0800)]
gdb: Modify the output of "info breakpoints" and "delete breakpoints"
The output of "info breakpoints" includes breakpoint, watchpoint,
tracepoint, and catchpoint if they are created, so it should show
all the four types are deleted in the output of "info breakpoints"
to report empty list after "delete breakpoints".
It should also change the output of "delete breakpoints" to make it
clear that watchpoints, tracepoints, and catchpoints are also being
deleted. This is suggested by Guinevere Larsen, thank you.
$ make check-gdb TESTS="gdb.base/access-mem-running.exp"
$ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running
[...]
(gdb) break main
Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32.
(gdb) watch global_counter
Hardware watchpoint 2: global_counter
(gdb) trace maybe_stop_here
Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27.
(gdb) catch fork
Catchpoint 4 (fork)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32
2 hw watchpoint keep y global_counter
3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27
not installed on target
4 catchpoint keep y fork
Without this patch:
(gdb) delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) info breakpoints 3
No breakpoint or watchpoint matching '3'.
With this patch:
(gdb) delete breakpoints
Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y
(gdb) info breakpoints
No breakpoints, watchpoints, tracepoints, or catchpoints.
(gdb) info breakpoints 3
No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Approved-by: Kevin Buettner <kevinb@redhat.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Tom de Vries [Sat, 24 Feb 2024 10:00:20 +0000 (11:00 +0100)]
[gdb/build] Fix static cast of virtual base
With this change in bfd/development.sh:
...
-development=true
+development=false
...
we run into:
...
In file included from tui-data.h:28:0,
from tui-command.c:24:
gdb-checked-static-cast.h: In instantiation of \
‘T gdb::checked_static_cast(V*) [with T = tui_cmd_window*; V = tui_win_info]’:
tui-command.c:65:15: required from here
gdb-checked-static-cast.h:63:14: error: cannot convert from pointer to base \
class ‘tui_win_info’ to pointer to derived class ‘tui_cmd_window’ because \
the base is virtual
T result = static_cast<T> (v);
^~~~~~~~~~~~~~~~~~
...
Fix this by using dynamic_cast instead of gdb::checked_static_cast in
TUI_CMD_WIN and TUI_STATUS_WIN.
Tested on x86_64-linux, with development set to false.
Reported-By: Robert Xiao <spam_hole@shaw.ca> Reported-By: Simon Marchi <simark@simark.ca> Approved-By: Tom Tromey <tom@tromey.com>
PR build/31399
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399
Alan Modra [Sat, 24 Feb 2024 01:08:57 +0000 (11:38 +1030)]
PR25333, GAS is slow processing -fdebug-types-sections
gas needs to build lists of sections for each group. This arranges to
build the lists earlier, so they can be used when looking for sections
that belong to a group. Using the section hash table to find sections
by name, then by group isn't efficient when there are numerous groups
with the same section names. Using a hash table to quickly find a
group, then searching by section name on a list for the group results
in a 100-fold speed improvement assembling the testcase in this PR.
To reduce the number of times we traverse the section list, the patch
also moves some processing done in elf_adjust_symtab for linked-to
section, to elf_frob_file. This requires a testsuite change because
processing will stop before elf_frob_file if there is a parse error in
section21.s, ie. you'll only get the "junk at end of line" error, not
the "undefined linked-to symbol" errors.
PR 25333
* config/obj-elf.c (struct group_list, groups): Move earlier.
(match_section): New function, extracted from..
(get_section_by_match): ..here.
(free_section_idx): Move earlier.
(group_section_find, group_section_insert): New functions.
(change_section): Use the above.
(elf_set_group_name): New function.
(obj_elf_attach_to_group): Use elf_set_group_name.
(set_additional_section_info): Handle linked_to_symbol_name and
stabs code, extracted from..
(adjust_stab_sections): ..here,..
(build_additional_section_info): ..and here.
(elf_adjust_symtab): Don't call build_additional_section_info.
(elf_frob_file): Adjust.
* config/obj-elf.h (elf_set_group_name): Declare.
* config/tc-xtensa.c (cache_literal_section): Use elf_set_group_name.
(xtensa_make_property_section): Likewise.
* testsuite/gas/elf/attach-1.d: Stricter group section matching,
and changed group section ordering.
* testsuite/gas/elf/attach-2.d: Stricter group section matching.
* testsuite/gas/elf/attach-2.s: Provide section bar type.
* testsuite/gas/elf/elf.exp: Run attach-2.
* testsuite/gas/elf/section21.l: Update.
* testsuite/gas/elf/section21.s: Don't check for a parse error.
Alan Modra [Wed, 21 Feb 2024 02:41:04 +0000 (13:11 +1030)]
Make is_relocatable_executable only affect dynamic section syms
I believe the only elflink.c specialties for is_relocatable_executable
needed by tic6x are those directly related to dynamic section symbols.
I might be wrong, the code in record_dynamic_symbol and
record_link_assignment predated the tic6x port, but I think these were
symbian specific hacks.
The shlib-app-1* testsuite changes aren't needed for this patch. I
started making them when trying to remove is_relocatable_executable
completely, but figure it is worth keeping the more permissive address
matching for some future generic linker change. The static-app-1*
changes also adjust to the fact that an unneeded "c" no longer appears
in the dynamic symbol table.
bfd/
* elflink.c (bfd_elf_link_record_dynamic_symbol): Don't do anything
special for is_relocatable_executable.
(bfd_elf_record_link_assignment): Likewise.
ld/
* testsuite/ld-tic6x/shlib-app-1.rd: Make some address matching
more permissive.
* testsuite/ld-tic6x/shlib-app-1b.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1r.rd: Likewise.
* testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise.
* testsuite/ld-tic6x/static-app-1.rd: Likewise, and adjust expected
dynamic symbol table.
* testsuite/ld-tic6x/static-app-1b.rd: Likewise.
* testsuite/ld-tic6x/static-app-1r.rd: Likewise.
* testsuite/ld-tic6x/static-app-1rb.rd: Likewise.
Pedro Alves [Tue, 20 Feb 2024 16:31:39 +0000 (16:31 +0000)]
Fix throw_winerror_with_name build error on x86-64 Cygwin
The GDB build currently fails on x86-64 Cygwin, with:
src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’:
src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=]
152 | error (_("%s (error %d): %s"), string, err, strwinerror (err));
| ^
Fix this by adding a cast. While at it, the error codes are really a
DWORD that results from a GetLastError() call, so I think unsigned is
more appropriate. That is also what strwinerror already does:
Jon Turney [Tue, 15 Sep 2020 15:38:06 +0000 (16:38 +0100)]
Drop special way of getting inferior context after a Cygwin signal
Simplify Cygwin signal handling by dropping the special way of getting
inferior context after a Cygwin signal.
I think the reason this existed was because previously we were not
able to unwind through the alternate stack used by _sigfe frames, so
without the hint of the "user" code IP, the backtrace from a signal
was unusable.
Now we can unwind through _sigfe frames, drop all this complexity.
(Restoring this specially obtained context to the inferior (as the
code currently does) skips over the actual signal delivery and
handling. Cygwin has carried for a long time a patch which clears the
ContextFlags in the signal context, so we never attempt to restore it
to the inferior, but that interfers with gdb's ability to modify that
context e.g. if it decides it wants to turn on FLAG_TRACE_BIT.)
Jon Turney [Tue, 12 Jan 2016 22:49:09 +0000 (22:49 +0000)]
Teach gdb how to unwind cygwin _sigbe and sigdelayed frames
The majority of functions in the cygwin DLL are wrapped by routines
which use an an alternate stack to return via a signal handler if a
signal occured while inside the function. (See [1],[2])
At present, these frames cannot be correctly unwound by gdb. There
doesn't seem to currently be a way to correctly describe these frames
using DWARF CFI.
So instead, write a custom unwinder for _sigbe and sigdelayed frames,
which gets the return address from the alternate stack.
The offset of tls::stackptr from TIB.stacktop is determined by analyzing
the code in _sigbe or sigdelayed.
This can backtrace from _sigbe and from a sighandler through sigdelayed.
Implemented for amd64 and i386
Issues:
1. We should detect if we are in the wrapper after the return address
has been popped off the alternate stack, and if so, fetch the return
address from the register it's been popped into.
2. If there are multiple _sigbe or sigdelayed stack frames to be
unwound, this only unwinds the first one correctly, because we don't
unwind the value of the alternate stack pointer itself.
This is no worse than currently, when we can't even unwind one of
these frame correctly, but isn't quite correct.
I guess this could be handled by defining a pseudo-register to track
its value as we unwind the stack.
Jan Beulich [Fri, 23 Feb 2024 11:00:43 +0000 (12:00 +0100)]
x86: rename vec_encoding and vex_encoding_*
Even with just VEX these weren't limited to vector insns. With APX the
set of non-vector ones covered has greatly increased. Drop the vec_
prefix. Also drop the vex_ ones off of the enumerators, as they weren't
appropriate anyway: Should have been vec_ then, too.
Jan Beulich [Fri, 23 Feb 2024 10:59:09 +0000 (11:59 +0100)]
x86: also permit YMM/ZMM use in CFI directives
Next to code using %ymm<N> or %zmm<N> it is more natural to have .cfi_*
directives also reference those, not the corresponding %xmm<N>. Accept
their names as kind of aliases, i.e. resolving to the same numbers.
While extending the respective 64-bit testcase, also add %bnd<N> there
(should have happened right with 633789901c83 ["x86-64: Dwarf2 register
numbers for %bnd<N>"], sorry), requiring binutils/dwarf.c to be adjusted
accordingly as well.
Jan Beulich [Fri, 23 Feb 2024 10:58:15 +0000 (11:58 +0100)]
x86/APX: INV{EPT,PCID,VPID} are WIG
While various other entries in version 003 of the spec aren't quite as
explicit (due to simply leaving the respective field blank), all three
have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0
by default (and respect -mevexwig=).
mengqinggang [Mon, 5 Feb 2024 08:16:52 +0000 (16:16 +0800)]
LoongArch: gas: Try to avoid R_LARCH_ALIGN associate with a symbol
The R_LARCH_ALIGN need to associated with a symbol if .align has the first
and third expressions. If R_LARCH_ALIGN associate with a symbol, the addend can
represent the first and third expression of .align.
For '.align 3', the addend of R_LARCH_ALIGN only need to represent the alignment
and R_LARCH_ALIGN not need to associate with a symbol.
For '.align x, , y', R_LARCH_ALIGN need to associate with a symbol if 0 < y <
2^x - 4.
Tom de Vries [Thu, 22 Feb 2024 10:35:26 +0000 (11:35 +0100)]
[gdb/dap] Fix race between dap startup and dap log file
In dap_gdb_start we do:
...
append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap"
...
While the dap log file setting comes before the dap interpreter setting,
the order is the other way around:
- first, the dap interpreter is started
- second, the -iex commands are executed and the log file is initialized.
Consequently, there's a race between dap interpreter startup and dap log file
initialization.
This cannot be fixed by using -eiex instead. Before the interpreter is
started, the "set debug dap-log-file" command is not yet registered.
Fix this by postponing the start of the DAP server until GDB has processed all
command files.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31386
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386
Tom de Vries [Thu, 22 Feb 2024 10:35:26 +0000 (11:35 +0100)]
[gdb/dap] Factor out thread_log
In thread_wrapper I used a style where a message is prefixed with the thread
name.
Factor this out into a new function thread_log.
Also treat the GDB main thread special, because it's usual name is MainThread:
...
MainThread: <msg>
...
which is the default name assigned by python, so instead use the more
explicit:
...
GDB main: <msg>
...
Tom Tromey [Wed, 7 Feb 2024 19:46:22 +0000 (12:46 -0700)]
Don't allow multiple request registrations in DAP
This changes the DAP code to check that a given request or capability
is only registered a single time. This is just a precaution against
accidentally introducing a second definition of a request somewhere.
Simon Marchi [Wed, 21 Feb 2024 16:46:52 +0000 (11:46 -0500)]
gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable}
This code was there to support g++ 4, which didn't support
std::is_trivially_constructible and std::is_trivially_copyable. Since
we now require g++ >= 9, I think it's fair to assume that GDB will
always be compiled with a compiler that supports those.
Tom de Vries [Wed, 21 Feb 2024 13:25:31 +0000 (14:25 +0100)]
[gdb/testsuite] Fix error handling in _dap_read_json
In _dap_read_json we have a gdb_expect with clauses that generate errors:
...
timeout {
error "timeout reading json header"
}
eof {
error "eof reading json header"
}
...
Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar
semantics related to errors:
...
# remote_expect works basically the same as standard expect, but it
# also takes care of getting the file descriptor from the specified
# host and also calling the timeout/eof/default section if there is an
# error on the expect call.
.....
When a timeout triggers, it generates a timeout error, which is reported by
gdb_expect, after which it runs the timeout/eof/default clauses, which
generates an eof error, which is reported by runtest.
I think the intention here is to generate just a one error, a timeout error.
Fix this by postponing generating the error until after gdb_expect.
Tested on x86_64-linux, by:
- running all the DAP test-cases and observing no regressions, and
- modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and
observing only a timeout error.
Yuriy Kolerov [Wed, 14 Feb 2024 18:16:16 +0000 (18:16 +0000)]
arc: Determine a branch target of DBNZ correctly
DBNZ instruction was moved from BRANCH class to a separate one - DBNZ.
Thus, it must be processed separately in arc_insn_get_branch_target
to correctly determine an offset for a possible branch.
The testsuite for DBNZ instruction verifies these cases:
1. Check that dbnz does not branch and falls through if its source
register is 0 after decrementing. GDB must successfully break
on the following instruction after stepping over.
2. Check that dbnz branches to the target correctly if its source register
is not 0 after decrementing - GDB must successfully break on the target
instruction if a forward branch is performed after stepping over.
3. The same as point 2 but for a backward branching case.
Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift
exponent 64 is too large". This is on the bucket_high_pc calculation
which was moved to the top of insert_arange_in_trie where previously
it was later, at a point where the overflow could not occur. Move it
back and arrange for a duplicate calculation of bucket_high_pc which
is also protected from overflow.
Alan Modra [Tue, 20 Feb 2024 23:13:40 +0000 (09:43 +1030)]
Remove is_relocatable_executable from backend code
With the removal of symbian support, most targets no longer or never
did set is_relocatable_executable. Remove the backend support that is
no longer relevant.
Matthieu Longo [Thu, 15 Feb 2024 14:39:43 +0000 (14:39 +0000)]
aarch64: testsuite: move sysreg tests into sysreg sub-directory
This patch moves the existing sysreg tests for AArch64 into a subdirectory
(sysreg). The number of test files related to system registers grew
relatively big with time and makes the browsing of those files difficult.
Moreover, the difference of naming for the failure, working, and
feature-specific scenarios causes the tests not to appear next to one
another in the exploration tree when it is ordered alphabetically.
Tom de Vries [Wed, 21 Feb 2024 09:46:08 +0000 (10:46 +0100)]
[gdb/dap] Join JSON writer thread with DAP thread
The DAP interpreter runs in its own thread, and starts a few threads:
- the JSON reader thread,
- the JSON writer thread, and
- the inferior output reader thread.
As part of the DAP shutdown, both the JSON reader thread and the JSON writer
thread, as well as the DAP main thread run to exit, but these exits are not
ordered in any way.
Wait in the main DAP thread for the exit of the JSON writer thread.
This makes sure that the responses are flushed to the DAP client before DAP
shutdown.
An earlier version of this patch used Queue.task_done() to accomplish the
same, but that didn't guarantee writing the "<thread name>: terminating"
log entry from thread_wrapper before DAP shutdown.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31380
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380
Tom de Vries [Wed, 21 Feb 2024 09:46:08 +0000 (10:46 +0100)]
[gdb/dap] Make dap log printing thread-safe
I read that printing from different python threads is thread-unsafe, and I
noticed that the dap log printing is used from different threads, but doesn't
take care to make the printing thread-safe.
Fix this by using a lock to access LoggingParam.log_file.
Tom de Vries [Wed, 21 Feb 2024 09:46:08 +0000 (10:46 +0100)]
[gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp
While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP
patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap
log file.
This is normally set up by dap_gdb_start, but the test-case doesn't use it.
Fix this by doing "set debug dap-log-file $logfile" in the test-case.
To make it easy to do so, I've factored out a new proc new_dap_log_file, and
while at likewise a new proc current_dap_log_file.
Tatsuyuki Ishi [Tue, 20 Feb 2024 17:55:48 +0000 (02:55 +0900)]
RISC-V: Fix local GOT and reloc size calculation for TLS.
The previous code did not account correctly for two cases:
* A TLS symbol can be referenced with multiple TLS types (although rare),
in which case it only allocated the maximum slot size among the types,
instead of the sum.
* TLS relocations are only needed for DLLs, unlike normal symbols which
requires relocations for all PIE code.
Modify the logic to account for the two cases, so this fixes the redundant
dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE.
Passed the gcc/binutils regressions of riscv-gnu-toolchain.
bfd/
* elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation
sizing for TLS and non-TLS symbols differently, with the former
requiring relocs on DLL while the latter requiring on PIE.
Allocate GOT slots and relocation slots for each TLS type separately,
accounting for the possibility of a TLS variable getting referenced by
multiple symbols.
ld/
* testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
* testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with
symbols referred by both types and global and local symbols.
Nelson Chu [Mon, 29 Jan 2024 13:17:41 +0000 (21:17 +0800)]
RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax.
Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c. Theoretically,
assembler don't need to generate the pc-relative relocation and the refered
local .L symbol when relaxation is disabled. The above commit improved the
pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump
relocations.
Passed the gcc/binutils regressions of riscv-gnu-toolchain.
gas/
* config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all
branch and jump relocations when -mno-relax.
Tom Tromey [Tue, 30 Jan 2024 17:06:46 +0000 (10:06 -0700)]
Rewrite Rust slice type handling
This patch rewrites the handling of slice types in Rust.
More recent versions of the Rust compiler changed how unsized types
were emitted, letting gdb inspect them more nicely. However, gdb did
not do this, and in fact treated all such types as if they were slices
of arrays, which is incorrect.
This patch rewrites this handling and removes the restriction that
unsized types must be array slices. I've added a comment explaining
how unsized types are represented to rust-lang.c as well.
I looked into a different approach, namely changing the DWARF reader
to fix up slice types to have a dynamic type. However, the approach
taken here turned out to be simpler.
Tested on x86-64 Fedora 38 with a variety of Rust compiler versions.
Tom Tromey [Sat, 10 Feb 2024 22:03:18 +0000 (15:03 -0700)]
Add obj_section::contains method
I noticed a number of spots checking whether an address is in an
obj_section. This patch introduces a new method for this and changes
some code to use it.
Simon Marchi [Mon, 19 Feb 2024 18:07:47 +0000 (13:07 -0500)]
gdb: pass frames as `const frame_info_ptr &`
We currently pass frames to function by value, as `frame_info_ptr`.
This is somewhat expensive:
- the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass
by value
- the constructors and destructor link/unlink the object in the global
`frame_info_ptr::frame_list` list. This is an `intrusive_list`, so
it's not so bad: it's just assigning a few points, there's no memory
allocation as if it was `std::list`, but still it's useless to do
that over and over.
As suggested by Tom Tromey, change many function signatures to accept
`const frame_info_ptr &` instead of `frame_info_ptr`.
Some functions reassign their `frame_info_ptr` parameter, like:
I wondered what to do about them, do I leave them as-is or change them
(and need to introduce a separate local variable that can be
re-assigned). I opted for the later for consistency. It might not be
clear why some functions take `const frame_info_ptr &` while others take
`frame_info_ptr`. Also, if a function took a `frame_info_ptr` because
it did re-assign its parameter, I doubt that we would think to change it
to `const frame_info_ptr &` should the implementation change such that
it doesn't need to take `frame_info_ptr` anymore. It seems better to
have a simple rule and apply it everywhere.
Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>
Paul Iannetta [Thu, 15 Feb 2024 09:30:47 +0000 (10:30 +0100)]
kvx: gas: missing aliases for $r14r15 in assembler.
Most registers from a register-pair suffixed by .lo and .hi suffixes.
This was not the case of $r14 and $r15 since they are defined by the
ABI: $r14 is the frame pointer, and $r15 is used to return aggregates
from functions. We do not add aliases for $r12 (the stack pointer) and
$r13 (the tls register).
Paul Iannetta [Mon, 12 Feb 2024 13:37:29 +0000 (14:37 +0100)]
kvx: gas: rename: or -> ior, xor -> eor
TCA instructions start with an X, this introduces ambiguities when it
comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this
reason, we rename OR to IOR and XOR to EOR.
OR and XOR variants are still valid on KV3-1 and KV3-2. However, they
have been completely removed from KV4-1.
Paul Iannetta [Fri, 8 Sep 2023 13:22:04 +0000 (15:22 +0200)]
kvx: Improve lexing & parsing
Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates,
however this candidate can be directly extracted from the array (in
kvx-parse.h) registering all the immediates.
During lexing, we ignored trailing characters after a number, this is
not good enough since now number can be followed by a modifier. The
function READ_TOKEN and GET_TOKEN_CLASS have been update to take this
into account.
gas/ChangeLog:
* config/kvx-parse.c (promote_token): Do not rely on
env.promote_immediate anymore.
(get_token_class): Do not ignore trailing characters after a
number.
(read_token): Likewise.
(print_token_list): THIS SHOULD NOT BE HERE.
Paul Iannetta [Mon, 4 Sep 2023 13:31:53 +0000 (15:31 +0200)]
kvx: gas: fix the detection of negative powers of 2
The detection of negative powers of 2 was wrong and could lead to
well-formed bundles ending up taking more syllables than necessary.
gas/ChangeLog:
* config/kvx-parse.c (get_token_class): Use the signed value.
* testsuite/gas/kvx/np2-detection.d: New test.
* testsuite/gas/kvx/np2-detection.s: New test.
Will Hawkins [Mon, 19 Feb 2024 18:24:19 +0000 (19:24 +0100)]
bpf: fix bpf expression parsing regression in GAS
As a result of a switch instead of an if, as would issue non-specific
error messages when it encountered an operand it could not parse in bpf.
This patch fixes that regression and adds a test to prevent it from
reoccurring.
Tested for bpf-unknown-none on x86_64-redhat-linux.
gas/ChangeLog:
* config/tc-bpf.c (parse_expression): Change switch to if so that error
* condition is handled.
* testsuite/gas/bpf/bpf.exp: Invoke new test.
* testsuite/gas/bpf/indcall-badoperand.d: New test.
* testsuite/gas/bpf/indcall-badoperand.l: New test.
* testsuite/gas/bpf/indcall-badoperand.s: New test.
Jose E. Marchesi [Mon, 19 Feb 2024 19:39:48 +0000 (20:39 +0100)]
bpf: gas: avoid UB in pointer subtraction
The PARSE_ERROR macro in md_assemble performs pointer subtraction. If
parse_expression returns NULL then the later will be part of the
subtraction and therefore UB will be incurred.
This patch changes md_assemble to:
1. Accommodate all invocations to parse_expression to the fact it will
return NULL when a parse error occurs.
2. Avoid UB in PARSE_ERROR.
Tested in bpf-unknown-none target / x86_64-linux-gnu host.
gas/ChangeLog:
* config/tc-bpf.c (md_assemble): Fix to take into account that
parse_expression can return NULL.
(PARSE_ERROR): Avoid passing invalid length to parse_error.
Yury Khrustalev [Fri, 9 Feb 2024 13:52:14 +0000 (13:52 +0000)]
aarch64: Add support for the id_aa64isar3_el1 system register
Hi,
[PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register
AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.
Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.
Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf?
Thanks,
Yury Khrustalev
From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001
From: Yury Khrustalev <yury.khrustalev@arm.com>
Date: Tue, 6 Feb 2024 11:05:39 +0000
Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the
id_aa64isar3_el1 system register
AArch64 defines a read-only system register called id_aa64isar3_el1.
This patch also adds relevant tests.
Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets
and no regressions was found.
Zac Walker [Wed, 31 Jan 2024 19:15:48 +0000 (20:15 +0100)]
aarch64: Add new relocations and limit COFF AArch64 relocation offsets
The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation
type. This is needed for 32-bit relative address.
It also adds a check for relocation offsets over 21 bits. Offsets
inside coff files are stored in instruction code. In the case of ADRP
the actual value is stored, not a downshifted page offset. This means
values over 21 bits would otherwise be truncated.
Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and
BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped.
ChangeLog:
* bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add
BFD_RELOC_AARCH64_ADR_GOT_PAGE,
BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32
relocations.
(coff_pe_aarch64_relocate_section): Likewise.
* gas/write.c (adjust_reloc_syms): COFF AArch64 relocation
offsets need to be limited to 21bits
(defined): Likewise.
gdb, python: selectively omit enabling stdin in gdb.execute
From the Python API, we can execute GDB commands via gdb.execute. If
the command gives an exception, however, we need to recover the GDB
prompt and enable stdin, because the exception does not reach
top-level GDB or normal_stop. This was done in commit
gdb: Enable stdin on exception in execute_gdb_command
with the following code:
catch (const gdb_exception &except)
{
/* If an exception occurred then we won't hit normal_stop (), or have
an exception reach the top level of the event loop, which are the
two usual places in which stdin would be re-enabled. So, before we
convert the exception and continue back in Python, we should
re-enable stdin here. */
async_enable_stdin ();
GDB_PY_HANDLE_EXCEPTION (except);
}
In this patch, we explain what happens when we run a GDB command in
the context of a synchronous command, e.g. via Python observer
notifications.
As an example, suppose we have the following objfile event listener,
specified in a file named file.py:
~~~
import gdb
class MyListener:
def __init__(self):
gdb.events.new_objfile.connect(self.handle_new_objfile_event)
self.processed_objfile = False
def handle_new_objfile_event(self, event):
if self.processed_objfile:
return
Using this Python file, we see the behavior below:
$ gdb -q -ex "source file.py" -ex "run" --args a.out
Reading symbols from a.out...
Starting program: /tmp/a.out
loading /lib64/ld-linux-x86-64.so.2
[New inferior 2]
Added inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
stdin/stdout redirected
Process /tmp/a.out created; pid = 3075406
Remote debugging using stdio
Reading /tmp/a.out from remote target...
...
[Switching to inferior 1 [process 3075400] (/tmp/a.out)]
[Switching to thread 1.1 (process 3075400)]
#0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
(gdb) [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 3075400) exited normally]
Note how the GDB prompt comes in-between the debugger output. We have this
obscure behavior, because the executed command, "target remote", triggers
an invocation of `normal_stop` that enables stdin. After that, however,
the Python notification context completes and GDB continues with its normal
flow of executing the 'run' command. This can be seen in the call stack
below:
(top-gdb) bt
#0 async_enable_stdin () at src/gdb/event-top.c:523
#1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
#2 0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801
#3 0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225
#4 0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316
#5 0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175
#6 0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338
#7 0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280) at src/gdb/target.c:824
#8 0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735
#9 0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575
#10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529
#11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701
#12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411
#13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700
#14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
#22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52
#23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195
#24 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
#25 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
#26 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290
#27 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590
#28 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166
#29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
#30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
#31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
#32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
#33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416
#34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
#35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
#36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
#37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
#38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
#39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
#40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
#41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
#42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
#43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
#44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
#45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
#46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
#47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
(top-gdb)
The use of the "target remote" command here is just an example. In
principle, we would reproduce the problem with any command that
triggers an invocation of `normal_stop`.
To omit enabling the stdin in `normal_stop`, we would have to check the
context we are in. Since we cannot do that, we add a new field to
`struct ui` to track whether the prompt was already blocked, and set
the tracker flag in the Python context before executing a GDB command.
After applying this patch, the output becomes
...
Reading symbols from a.out...
Starting program: /tmp/a.out
loading /lib64/ld-linux-x86-64.so.2
[New inferior 2]
Added inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
stdin/stdout redirected
Process /tmp/a.out created; pid = 3032261
Remote debugging using stdio
Reading /tmp/a.out from remote target...
...
[Switching to inferior 1 [process 3032255] (/tmp/a.out)]
[Switching to thread 1.1 (process 3032255)]
#0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Inferior 1 (process 3032255) exited normally]
(gdb)
Let's now consider a secondary scenario, where the command executed from
the Python raises an error. As an example, suppose we have the Python
file below:
The executed command, "print a", gives an error because "a" is not
defined. Without this patch, we see the behavior below, where the
prompt is again placed incorrectly:
...
Reading symbols from /tmp/a.out...
Starting program: /tmp/a.out
loading /lib64/ld-linux-x86-64.so.2
Python Exception <class 'gdb.error'>: No symbol "a" in current context.
(gdb) [Inferior 1 (process 3980401) exited normally]
This time, `async_enable_stdin` is called from the 'catch' block in
`execute_gdb_command`:
(top-gdb) bt
#0 async_enable_stdin () at src/gdb/event-top.c:523
#1 0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713
#2 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#3 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#4 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#5 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#6 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#7 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#8 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0
#9 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104
#10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52
#11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195
#12 0x0000555555d6dff0 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:61
#13 0x0000555555d6be18 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x5555585b5860: 0x5555563b5360 <python_new_objfile(objfile*)>) at /usr/include/c++/11/bits/invoke.h:111
#14 0x0000555555d69661 in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290
#15 0x0000555556314caf in std::function<void (objfile*)>::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590
#16 0x000055555631444e in gdb::observers::observable<objfile*>::notify (this=0x55555836eea0 <gdb::observers::new_objfile>, args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166
#17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125
#18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160
#19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692
#20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015
#21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416
#22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058
#23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217
#24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275
#25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486
#26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512
#27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95
#28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735
#29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575
#30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab <execute_command(char const*, int)>, arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513
#31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612
#32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293
#33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314
#34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
#35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
(top-gdb)
Again, after we enable stdin, GDB continues with its normal flow
of the 'run' command and receives the inferior's exit event, where
it would have enabled stdin, if we had not done it prematurely.
(top-gdb) bt
#0 async_enable_stdin () at src/gdb/event-top.c:523
#1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432
#2 0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700
#3 0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42
#4 0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316
#5 0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573
#6 0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694
#7 0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217
#8 0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407
#9 0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471
#10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324
#11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343
#12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39
(top-gdb)
The solution implemented by this patch addresses the problem. After
applying the patch, the output becomes
$ gdb -q -ex "source file.py" -ex "run" --args a.out
Reading symbols from /tmp/a.out...
Starting program: /tmp/a.out
loading /lib64/ld-linux-x86-64.so.2
Python Exception <class 'gdb.error'>: No symbol "a" in current context.
[Inferior 1 (process 3984511) exited normally]
(gdb)
Regression-tested on X86_64 Linux using the default board file (i.e. unix).
Tom de Vries [Mon, 19 Feb 2024 08:59:15 +0000 (09:59 +0100)]
[gdb/exp] Fix printing of out of bounds struct members
When building gdb with -O0 -fsanitize=address, and running test-case
gdb.ada/uninitialized_vars.exp, I run into:
...
(gdb) info locals
a = 0
z = (a => 1, b => false, c => 2.0)
=================================================================
==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80
READ of size 4 at 0x602000097f58 thread T0
#0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18)
#1 0xbcab24 in unsigned char* std::__copy_move_backward<false, true, std::random_access_iterator_tag>::__copy_move_b<unsigned char const, unsigned char>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748
#2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769
#3 0xbc898c in unsigned char* std::__copy_move_backward_a1<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778
#4 0xbc715c in unsigned char* std::__copy_move_backward_a<false, unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807
#5 0xbc4e6c in unsigned char* std::copy_backward<unsigned char const*, unsigned char*>(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867
#6 0xbc2934 in void gdb::copy<unsigned char const, unsigned char>(gdb::array_view<unsigned char const>, gdb::array_view<unsigned char>) gdb/../gdbsupport/array-view.h:223
#7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239
#8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078
#9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095
#10 0xcafd64 in print_field_values gdb/ada-valprint.c:658
#11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857
#12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042
#13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04)
#14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092
#15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184
#16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
#17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
#18 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
#19 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
#20 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
#21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
#22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
#23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
#24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
#25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
#26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
#27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
#28 0x1384080 in command_handler(char const*) gdb/event-top.c:566
#29 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
#30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
#31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
#32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
#33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
#34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
#35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
#36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
#37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694
#38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264
#39 0x1768080 in start_event_loop gdb/main.c:408
#40 0x17684c4 in captured_command_loop gdb/main.c:472
#41 0x176cfc8 in captured_main gdb/main.c:1342
#42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361
#43 0xb73edc in main gdb/gdb.c:39
#44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8)
#45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac)
#46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c)
0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58)
allocated by thread T0 here:
#0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218)
#1 0xcbc278 in xcalloc gdb/alloc.c:97
#2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29
#3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937
#4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033
#5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector<range, std::allocator<range> > const&) gdb/value.c:229
#6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560
#7 0x20ca6fc in value_check_printable gdb/valprint.c:1133
#8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182
#9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355
#10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308
#11 0x1dabca0 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305
#12 0x1dabd14 in gdb::function_view<void (char const*, symbol*)>::bind<print_variable_and_value_data>(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299
#13 0x1dab34c in gdb::function_view<void (char const*, symbol*)>::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289
#14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240
#15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view<void (char const*, symbol*)>) gdb/stack.c:2259
#16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380
#17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458
#18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95
#19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735
#20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575
#21 0x1384080 in command_handler(char const*) gdb/event-top.c:566
#22 0x1384e2c in command_line_handler(std::unique_ptr<char, gdb::xfree_deleter<char> >&&) gdb/event-top.c:802
#23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104
#24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259
#25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290
#26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195
#27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234
#28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155
#29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573
SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove
...
The error happens when trying to print either variable y or y2:
...
type Variable_Record (A : Boolean := True) is record
case A is
when True =>
B : Integer;
when False =>
C : Float;
D : Integer;
end case;
end record;
Y : Variable_Record := (A => True, B => 1);
Y2 : Variable_Record := (A => False, C => 1.0, D => 2);
...
when the variables are uninitialized.
The error happens only when printing the entire variable:
...
(gdb) p y.a
$2 = 216
(gdb) p y.b
There is no member named b.
(gdb) p y.c
$3 = 9.18340949e-41
(gdb) p y.d
$4 = 1
(gdb) p y
<AddressSanitizer: heap-buffer-overflow>
...
The error happens as follows:
- field a functions as discriminant, choosing either the b, or c+d variant.
- when y.a happens to be set to 216, as above, gdb interprets this as the
variable having the c+d variant (which is why trying to print y.b fails).
- when printing y, gdb allocates a value, copies the bytes into it from the
target, and then prints the value.
- gdb allocates the value using the type size, which is 8. It's 8 because
that's what the DW_AT_byte_size indicates. Note that for valid values of a,
it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1
(b variant), size is 8.
- gdb tries to print field d, which is at an 8 byte offset, and that results
in a out-of-bounds access for the allocated 8-byte value.
Fix this by handling this case in value::contents_copy_raw, such that we have:
...
(gdb) p y
$1 = (a => 24, c => 9.18340949e-41,
d => <error reading variable: access outside bounds of object>)
...
An alternative (additional) fix could be this: in compute_variant_fields_inner
gdb reads the discriminant y.a to decide which variant is active. It would be
nice to detect that the value (y.a == 24) is not a valid Boolean, and give up
on choosing a variant altoghether. However, the situation regarding the
internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not
possible to reliably decide what valid values are.
The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is
a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the
copyright years.
Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc
versions. [ So, it would be nice to rewrite it into a dwarf assembly
test-case. ]
The test-case loops over all languages. This is inherited from an earlier
attempt to fix this, which had language-specific fixes (in print_field_values,
cp_print_value_fields, pascal_object_print_value_fields and
f_language::value_print_inner). I've left this in, but I suppose it's not
strictly necessary anymore.
Alan Modra [Fri, 16 Feb 2024 12:03:29 +0000 (22:33 +1030)]
PR27597, nios: assertion fail in nios2_elf32_install_imm16
The assertion in nios2_elf32_install_imm16 triggers when the PLT is
twice the maximum allowable size for a branch from PLTn to reach
.PLTresolve, and on no other call to nios2_elf32_install_imm16. That
makes the assertion completely useless. We can handle a PIC PLT
exceeding 0x8000 in size by bouncing branches that won't reach through
previous branches.
PR 27597
* elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT.
(nios2_build_one_stub): Don't bother masking value passed to
nios2_elf32_install_imm16.
(nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow
of PLTn branch to .PLTresolve by bouncing through prior branches.
Jan Beulich [Fri, 16 Feb 2024 09:20:08 +0000 (10:20 +0100)]
x86/APX: drop stray IgnoreSize
While necessary on the legacy encodings, the EVEX ones don't need it.
Even more so when they're available for 64-bit mode only, when the
legacy encodings have the attribute only for correctly handling things
in 16-bit mode.
Jan Beulich [Fri, 16 Feb 2024 09:19:11 +0000 (10:19 +0100)]
x86: don't use VexWIG in SSE2AVX templates
Several years ago it was decided that SSE2AVX templates should not be
sensitive to -mvexwig= (upon my suggestion to consistently make all
sensitive as long as they don't require a specific setting of VEX.W).
Adjust the four that still are, switching to use of Vex128 at the same
time.
projects / thirdparty / binutils-gdb.git / log
