Tatsuyuki Ishi [Tue, 20 Feb 2024 17:55:52 +0000 (02:55 +0900)]
RISC-V: Initial ld.bfd support for TLSDESC.
Only relocation handling for now; relaxation is not implemented yet.
bfd/
* elfnn-riscv.c (riscv_elf_check_relocs): Record GOT reference and
paired relocation for TLSDESC_HI20.
(riscv_elf_adjust_dynamic_symbol): Allocate GOT and reloc slots for
TLSDESC symbols.
(riscv_elf_size_dynamic_sections): Likewise but for local symbols.
(tlsdescoff): New helper to determine static addend for R_TLSDESC.
(riscv_elf_relocate_section): Ignore TLSDESC_CALL reloc for now (it is
relaxation only).
Handle TLSDESC_{LOAD,ADD}_LO12 as paired pcrel relocs.
For TLS GOT slot generation, generalize the logic to handle any
combination of (GD, IE, TLSDESC).
Add TLSDESC Rela generation.
* ld/testsuite/ld-riscv-elf/tls*: Add TLSDESC instruction sequences
next to the existing GD and IE sequences. Update expectations.
Tatsuyuki Ishi [Tue, 20 Feb 2024 17:55:51 +0000 (02:55 +0900)]
RISC-V: Define and use GOT entry size constants for TLS.
As the size calculation is split by global and local symbols, using a
shared constant definition for its size improves clarity.
bfd/
* elfnn-riscv.c: Add macros for sizes of a normal GOT entry, TLS GD and
TLS IE entry.
(allocate_dynrelocs): Replace GOT size expressions with the new
constants.
(riscv_elf_size_dynamic_sections): Likewise.
(riscv_elf_relocate_section): Likewise.
Tatsuyuki Ishi [Tue, 20 Feb 2024 17:55:50 +0000 (02:55 +0900)]
RISC-V: Add assembly support for TLSDESC.
gas/
* tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi,
%tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype
renamed to percent_op_relax_only as this matcher is extended to handle
jalr as well which is not R-type.
(riscv_ip): Apply the percent_op_relax_only rename and update comment.
(md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to
TLS relocation check list.
* testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation
generation.
opcodes/
* riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with
%tlsdesc_call annotations.
Tom Tromey [Fri, 23 Feb 2024 15:59:40 +0000 (08:59 -0700)]
Fix gdb.interrupt race
gdb.interrupt was introduced to implement DAP request cancellation.
However, because it can be run from another thread, and because I
didn't look deeply enough at the implementation, it turns out to be
racy.
The fix here is to lock accesses to certain globals in extension.c.
Note that this won't work in the case where configure detects that the
C++ compiler doesn't provide thread support. This version of the
patch disables DAP entirely in this situation.
Regression tested on x86-64 Fedora 38. I also ran gdb.dap/pause.exp
in a thread-sanitizer build tree to make sure the reported race is
gone.
Alan Modra [Wed, 28 Feb 2024 08:23:52 +0000 (18:53 +1030)]
PR23881, pdp11 binutils fails if too much debug data
The PR testcase overflows one of the exec header fields, e_syms (the
size of the symbol table), leading to the string table offset being
wrong. Things go downhill from there. Fixed by checking for
overflow. This happens to trigger in the ld testsuite, so xfail that
test.
Tom Tromey [Fri, 23 Feb 2024 20:51:58 +0000 (13:51 -0700)]
Explicitly quit gdb from DAP server thread
This changes the DAP code to explicitly request that gdb exit.
Previously this could cause crashes, but with the previous cleanups,
this should no longer happen.
This also adds a tests that ensures that gdb exits with status 0.
Tom Tromey [Fri, 23 Feb 2024 20:26:02 +0000 (13:26 -0700)]
Add final cleanup for runnables
This changes run-on-main-thread.c to clear 'runnables' in a final
cleanup. This avoids an issue where a pending runnable could require
Python, but be run after the Python interpreter was finalized.
Tom Tromey [Fri, 23 Feb 2024 20:18:49 +0000 (13:18 -0700)]
Add extension_language_ops::shutdown
Right now, Python is shut down via a final cleanup. However, it seems
to me that it is better for extension languages to be shut down
explicitly, after all the ordinary final cleanups are run. The main
reason for this is that a subsequent patch adds another case like
finalize_values; and rather than add a series of workarounds for
Python shutdown, it seemed better to let these be done via final
cleanups, and then have Python shutdown itself be the special case.
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.
projects / thirdparty / binutils-gdb.git / log
