Jan Beulich [Fri, 5 Sep 2025 06:32:25 +0000 (08:32 +0200)]
x86: make reloc() usable during late phases of assembly
Introduce a clone with extra parameters, to allow subsequent use from
md_estimate_size_before_relax() (or elsewhere, should that turn out
necessary). There flag_code cannot be used and location information
needs to be provided for diagnostics.
Andrew Burgess [Mon, 1 Sep 2025 16:00:15 +0000 (17:00 +0100)]
gdb/dap: check values are available before converting to int
In VariableReference.to_object, we try to convert a gdb.Value to an
int without checking if the value is actually available. This came to
light in PR gdb/33345, after the x86 CET shadow stack patches were
merged.
If the x86 CET shadow stack register is available on the machine,
but the shadow stack feature is not enabled at run time, then the
register will show as "<unavailable>".
As the register is of type 'void *', then in the DAP code we try to
add a 'memoryReference' attribute with the value of the register
formatted as hex. This will fail if the register is unavailable.
To test this change you'll need:
(a) a machine which support the shadow stack feature, and
(b) to revert the changes from commit 63b862be762e1e6e7 in the file
gdb.dap/scopes.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345 Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Add a new gdb.Value.is_unavailable attribute. This is similar to the
existing Value.is_optimized_out attribute, but returns True if any
part of the value is <unavailable>.
The existing Value.is_optimized_out attribute returns true if any part
of the value is optimized out, so I thought that Value.is_unavailable
should work the same way.
Pawel Kupczak [Thu, 28 Aug 2025 11:50:15 +0000 (11:50 +0000)]
gdb, amd64: extend the amd64 prologue analyzer to skip stack alloc
Following the previous patch (gdb, amd64: extend the amd64 prologue
analyzer to skip register pushes), this patch extends the analyzer
further to be able to skip stack space allocation as the next prologue
part, for functions with a frame pointer. Implementation was based
on the i386 counterpart, which already had that functionality.
As of now, the stack allocation is not skipped. Examples below use C
source listed below, compiled with gcc 11.4.0.
```
int foo (int n)
{
int ns[] = { 1, 4, 9, 16, 25 };
return ns[n];
}
int
main (int argc, char **argv)
{
return foo (argc);
}
```
Compiling with "gcc -O0 -fno-omit-frame-pointer" we get:
```
(gdb) b foo
Breakpoint 1 at 0x1151
(gdb) r
...
Breakpoint 1, 0x0000555555555151 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: push %rbp
0x000055555555514e <+5>: mov %rsp,%rbp
=> 0x0000555555555151 <+8>: sub $0x30,%rsp
0x0000555555555155 <+12>: mov %edi,-0x24(%rbp)
...
```
With this patch, it gets skipped the same way register pushes are:
```
(gdb) b foo
Breakpoint 1 at 0x1155
(gdb) r
...
Breakpoint 1, 0x0000555555555155 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555149 <+0>: endbr64
0x000055555555514d <+4>: push %rbp
0x000055555555514e <+5>: mov %rsp,%rbp
0x0000555555555151 <+8>: sub $0x30,%rsp
=> 0x0000555555555155 <+12>: mov %edi,-0x24(%rbp)
...
```
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
Pawel Kupczak [Thu, 28 Aug 2025 11:50:13 +0000 (11:50 +0000)]
gdb, amd64: extend the amd64 prologue analyzer to skip register pushes
A typical function's prologue can consist of setting up a frame pointer,
pushing registers onto the stack and allocating space on the stack.
Current amd64 prologue analyzer would stop after the frame setup.
This patch allows GDB to skip past register pushes, while also improving
unwinding pushed registers, for functions with a frame pointer, without
debug info and .cfi directives found in .eh_frame section that are used
for unwinding. Skipping register pushes was also present for i386
targets before - the proposed changes are based on i386 implementation.
It also improves the unwinding even if .cfi directives are present,
because GDB can only unwind a register if it has reached a corresponding
.cfi directive, which won't be there before the pushes.
Additionally, at least gcc 11.4 and later by default doesn't emit
necessary debug info, which GDB would try to use to find prologue's end.
In that case, extended prologue analyzer would take effect.
Using C source listed below as an example, compiled with gcc 11.4.0:
```
int __attribute__ ((noinline))
bar (int a)
{
return a + a;
}
int __attribute__ ((noinline))
foo (int a, int b, int c, int d, int e)
{
int x = bar (a) + bar (b) + bar (c) + bar (d) + bar (e);
return x;
}
int
main (int argc, char **argv)
{
return foo (1, 2, 3, 4, 5);
}
```
Compiling with "gcc -O1 -fno-omit-frame-pointer
-fno-asynchronous-unwind-tables", we get:
```
(gdb) b foo
Breakpoint 1 at 0x1139
(gdb) r
...
Breakpoint 1, 0x0000555555555139 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
=> 0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
(gdb) ni
0x000055555555513b in foo ()
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1 0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 1234
```
With the proposed changes, breakpoint gets past those register pushes:
```
(gdb) b foo
Breakpoint 1 at 0x1142
(gdb) r
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
=> 0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
```
Also, unwinding pushed registers now works:
```
...
Breakpoint 1, 0x0000555555555142 in foo ()
(gdb) disassemble
Dump of assembler code for function foo:
0x0000555555555131 <+0>: endbr64
0x0000555555555135 <+4>: push %rbp
0x0000555555555136 <+5>: mov %rsp,%rbp
0x0000555555555139 <+8>: push %r15
0x0000555555555139 <+8>: push %r15
0x000055555555513b <+10>: push %r14
0x000055555555513d <+12>: push %r13
0x000055555555513f <+14>: push %r12
0x0000555555555141 <+16>: push %rbx
=> 0x0000555555555142 <+17>: sub $0x8,%rsp
0x0000555555555146 <+21>: mov %esi,%r15d
...
(gdb) p $r15
$1 = 140737354125376
(gdb) p $r15=1234
$2 = 1234
(gdb) p $r15
$3 = 1234
(gdb) up
#1 0x00005555555551b7 in main ()
(gdb) p $r15
$4 = 140737354125376
```
Additionally a new test was added to verify this behavior.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
I also considered changing gdbserver to not send Bss=, but decided
against this, reasoning that we may as well not break compatibility
with older versions of gdb.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33319 Approved-By: Simon Marchi <simon.marchi@efficios.com>
gdb/testsuite: fix possible TCL errors in gdb.threads/threadcrash.exp
The test gdb.threads/threadcrash.exp, among other things, creates a list
of the threads seen in the order that the "thread apply all backtrace"
would generate them, tests that this list is the same size as GDB's
count of threads, and then loops over the list to check that each
thread has the expected backtrace.
A problem occurs because the loop iterates on GDB's internal count of
threads, rather than the size of the list, but then attempts to acces
the n-th element of the list. If the list size is smaller than GDB's
internal thread count, it'll access past the end of the list and
generate TCL errors.
This commit fixes this by using the list's length instead.
Andrew Burgess [Wed, 27 Aug 2025 18:40:30 +0000 (19:40 +0100)]
gdb: remove most global core file accesses from fbsd-tdep.c
This commit removes many places in fbsd-tdep.c where we access the
current core file via current_program_space, and replaces these
accesses with a function argument that is passed in.
There are still two uses of 'current_program_space->core_bfd ()' in
the file, these will be addressed in future work (not in this series
though).
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 27 Aug 2025 10:49:24 +0000 (11:49 +0100)]
gdb: pass core file to gdbarch_core_xfer_siginfo
Another patch that aims to remove 'current_program_space->core_bfd ()'
from GDB. This time I'm passing the core file BFD as an argument to
the gdbarch method gdbarch_core_xfer_siginfo.
In corelow.c the core file is being passed, this does introduce a new
instance of 'current_program_space->core_bfd ()', but this is OK. My
long term plan is to move the core bfd into core_target, in which case
the call to gdbarch_core_xfer_siginfo will have access to the core bfd
as a member variable.
For now though, this patch moves the accesses via global state up the
call stack, and consolidates the two calls from fbsd-tdep.c and
linux-tdep.c into the one call in corelow.c.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 27 Aug 2025 10:30:47 +0000 (11:30 +0100)]
gdb: remove most global core file accesses from record-full.c
This commit continues my ongoing work to reduce the number of global
accesses to the current core file BFD in GDB. The global accesses I'm
working on removing look like 'current_program_space->core_bfd ()'.
This commit targets record-full.c. All global accesses are removed
except for two in record_full_open, which is used to implements the
two commands 'target record-full' and 'record full restore'.
All other global accesses to the core file are removed by passing the
core file through as an argument from this one top level function.
As I followed the code through I noticed that record_full_restore,
which currently includes this check:
if (current_program_space->core_bfd () == nullptr)
return;
could never actually be called without a core file being set. As the
argument is now 'struct bfd &', then there is no longer an option for
the incoming argument to be NULL, and the above check is removed.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 27 Aug 2025 18:51:56 +0000 (19:51 +0100)]
gdb: remove some dead code from core_target_open
In core_target_open we call target_preopen which pops all targets
above the file_stratum, this will include the core_target, if the core
target is currently loaded.
Currently, the core file BFD is stored in the program_space of an
inferior. The only way to set the core file BFD is by creating a
core_target (in core_target_open). And when a core_target is closed
the core file BFD within the program_space is reset to nullptr (see
core_target::close and core_target::clear_core, both in corelow.c).
What this means is that, if there is no core_target loaded then there
will be no core file BFD in the program_space. And in
core_target_open, after the call to target_preopen, there will be no
core_target loaded, and thus, no core file BFD in the program_space.
There is currently code in core_target_open which checks to see if
there is a core file BFD set in the current program space. For the
reasons given above, I believe this is dead code and can be removed.
I've added some asserts to validate my assumptions.
There should be no user visible changes after this commit.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom de Vries [Thu, 4 Sep 2025 14:15:26 +0000 (16:15 +0200)]
[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/powerpc*.exp
Fix clean_restart <absolute filename> in gdb.arch/powerpc*.exp.
Likewise in gdb.arch/ppc*.exp, gdb.arch/altivec*.exp, gdb.arch/e500*.exp and
gdb.arch/vsx*.exp.
Tested on ppc64le-linux.
The following test-cases only run on 32-bit ppc:
- gdb.arch/e500-abi.exp
- gdb.arch/e500-prologue.exp
- gdb.arch/e500-regs.exp
- gdb.arch/powerpc-aix-prologue.exp
- gdb.arch/powerpc-prologue.exp
- gdb.arch/powerpc-prologue-frame.exp
- gdb.arch/powerpc-trap.exp
so these haven't been tested.
Tom de Vries [Thu, 4 Sep 2025 14:15:26 +0000 (16:15 +0200)]
[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp
Fix clean_restart <absolute filename> in gdb.arch/aarch64*.exp.
Tested on aarch64-linux, M1 system.
There's a large number (44) of unsupported, for the following reasons:
- allow_aarch64_gcs_tests
- allow_aarch64_mops_tests
- allow_aarch64_sve_tests / target does not support SVE
- memory tagging unsupported
Consequently, we mostly use the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
Nelson Chu [Thu, 21 Aug 2025 04:33:04 +0000 (12:33 +0800)]
RISC-V: Don't generate R_RISCV_RELATIVE if symbol referenced section is SH_ABS
It's werid if it's absolute symbol but have a relative reloc for got entry
under pie. So don't generate relative reloc if symbol referenced section is
SH_ABS. However, x86 allows the absolute symbol defined in linker script has
a relative reloc, not sure if risc-v needs this or not.
Nelson Chu [Thu, 21 Aug 2025 04:33:03 +0000 (12:33 +0800)]
RISC-V: Don't overwrite got entry to zero for IRELATIVE/RELATIVE relocation
Even the final result is correct since we encode the relocation into r_addend,
so glibc won't need to get the content of got entry when resolving relative
relocation, it still werid that finish_dynamic_symbol cleans what we filled in
the relocate_section.
There are two problems when GOT relocation against a symbol that has a defined
value,
1. Pesudo la with pic and pseudo lga lost the relocations.
2. %got_pcrel_hi generates R_RISCV_GOT_HI20 with addend, which is wrong since
commit 50331d64f108.
The solution is to use deferred_expression for GOT relocation. Maybe other
relocations also have same problem and need the deferred_expression, but we can
add in the future patches.
Tom de Vries [Wed, 3 Sep 2025 16:09:41 +0000 (18:09 +0200)]
[gdb/testsuite] Fix clean_restart <absolute filename> in gdb.disasm
Fix clean_restart <absolute filename> in the test-cases in gdb.disasm.
The changed test-cases:
- gdb.disasm/am33.exp
- gdb.disasm/hppa.exp
- gdb.disasm/mn10300.exp
- gdb.disasm/sh3.exp
are unsupported for me, but the changes are trivial.
H.J. Lu [Wed, 3 Sep 2025 13:48:24 +0000 (06:48 -0700)]
readelf: Don't change the symbol table
1. Update dump_relr_relocations not to change the symbol table.
2. Update count_relr_relocations and dump_relr_relocations not to
retrieve the same data twice.
binutils/
PR binutils/33328
* readelf.c (count_relr_relocations): Add an argument to return
the retrieved data and remove the FIXME in comments.
(dump_relr_relocations): Add an argument for the retrieved data.
Retrieve the data if needed. Don't change the symbol table and
remove the FIXME in comments.
(display_relocations): Get the data from count_relr_relocations
and pass it to dump_relr_relocations call.
(process_relocs): Pass NULL to dump_relr_relocations.
ld/
PR binutils/33328
* testsuite/ld-i386/dt-relr-2.d: New file.
* testsuite/ld-i386/dt-relr-2.s: Likewise.
* testsuite/ld-x86-64/dt-relr-2-x32.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.d: Likewise.
* testsuite/ld-x86-64/dt-relr-2.s: Likewise.
* testsuite/ld-i386/i386.exp: Run dt-relr-2.
* testsuite/ld-x86-64/x86-64.exp: Run dt-relr-2 and dt-relr-2-x32.
Tiezhu Yang [Mon, 1 Sep 2025 01:29:56 +0000 (09:29 +0800)]
gdb: LoongArch: Restrict breakpoint outside of atomic sequence
We can't put a breakpoint in the middle of a ll/sc atomic sequence,
so look for the end of the sequence and put the breakpoint there,
it has been handled in the commit 208b57e53ed9 ("gdb: LoongArch:
Deal with atomic sequence").
Especially, maybe there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
current pc + 4 which is inside the atomic sequence, it should not
put a breakpoint in its destination address in this case, this has
been handled in the commit a4242dc3f5fa ("gdb: LoongArch: Improve
the handling of atomic sequence").
Additionally, if there is a conditional branch instruction in the
middle of a ll/sc atomic sequence, its destination address may be
not current pc + 4 but still inside the atomic sequence, it should
not put a breakpoint in its destination address in this case.
So in order to avoid putting a breakpoint in the middle of a ll/sc
atomic sequence in any case, just look for the start and end of the
sequence, and restrict the breakpoint outside of the atomic sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tiezhu Yang [Mon, 1 Sep 2025 01:29:55 +0000 (09:29 +0800)]
gdb: LoongArch: Add and use cond_branch_destination_address()
In the current loongarch_deal_with_atomic_sequence(), it is just a loop
through a ll/sc atomic instruction sequence, the instructions before the
condition branch are not actually executed, thus the condition register
value is not proper to determine the destination address.
Add a new function cond_branch_destination_address() to calculate the
destination address of a condition branch instruction under an assumed
true condition, then only put a breakpoint at this address when it is
outside of the ll/sc atomic instruction sequence.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Tom de Vries [Wed, 3 Sep 2025 12:18:35 +0000 (14:18 +0200)]
[gdb/testsuite] Fix clean_restart in gdb.opencl/callfuncs.exp
In test-case gdb.opencl/callfuncs.exp I noticed:
...
clean_restart [standard_testfile $testfile]
...
This doesn't have the desired effect of starting gdb with $testfile because
standard_testfile doesn't return anything.
Fix this by using "clean_restart $testfile".
While we're at it:
- move standard_testfile to the start of the file
- drop the redundant 'set testfile "callfuncs"'
- use standard_testfile .cl to properly define $srcfile
- use $srcfile instead of $testfile.cl
Tested on x86_64-linux, using the demonstrator patch in PR testsuite/33363.
gdb/testsuite: Fix gdb.base/gcore-memory-usage with address sanitizer
The test gdb.base/gcore-memory-usage is meant to show that the memory
requirements of GDB's gcore command don't grow with the memory usage
of the inferior. It was using hardcoded values for memory, but the
values were too small when building GDB with address sanitizer. This
commit fixes one of the failures by increasing the limit on the first
gcore call.
But, rather than just increasing the hardcoded limit for the second
call, we instead save the amount of memory used in the first call and
ensure that the second call doesn't use more memory than the first.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33148 Approved-By: Tom de Vries <tdevries@suse.de>
Alan Modra [Wed, 3 Sep 2025 00:24:50 +0000 (09:54 +0930)]
Disable eh_frame optimisation if code detected in .eh_frame
Fuzzers stress the assembler in ways no sane programmer would ever do.
One x86 oss-fuzz testcase (cleaned up a litte) was:
.sect .debug_frame
call x
.long x,0
.space 1
.long 0,0
The call insn leaves the frag data corresponding to a CIE
uninitialised until later in assembly, leading to reports of
uninitialised data access in ehopt.c:check_eh_frame.
Hack around this problem by noticing an insn has been assembled in
dwarf2_emit_insn. The existing frag has_code can't be used as that
leads to alignment complaints, so add a new segment_info flag.
* subsegs.h (struct segment_info_struct): Move bss and hadone
later. Rename hadone to stab_seen. Add insn_seen bitfield.
* dwarf2dbg.c (dwarf2_emit_insn): Set insn_seen.
* ehopt.c (check_eh_frame): Disable optimisation if insn_seen.
* stabs.c (s_stab_generic): Adjust for hadone rename.
Alan Modra [Wed, 3 Sep 2025 01:29:54 +0000 (10:59 +0930)]
frag_alloc use of obstack_alloc
Avoid the alignment hackery necessary when obstack_alloc is used.
obstack_alloc expands to obstack_blank plus obstack_finish, and the
latter call is where alignment of the tail of the obstack happens.
The docs say obstack_alloc "is invoked almost like malloc", which
implies a fixed size allocation and you don't need other obstack calls
in its use. So I think trying to use obstack_alloc in frag_alloc was
always a poor choice.
* frags.c (frag_alloc): Replace obstack_alloc with obstack_blank.
Alan Modra [Wed, 3 Sep 2025 00:20:17 +0000 (09:50 +0930)]
Explain frag alignment hacks
"the weird alignment hackery" comment doesn't help anyone understand
the code. Explain what is going on. Replace the zero length
obstack_alloc with obstack_finish, which by inspection of obstack.h is
all the zero length alloc does.
* frags.c (frag_alloc): Comment. Replace zero length
obstack_alloc with obstack_finish.
(frag_new): Remove unnecessary obstack_finish.
* write.c (compress_frag, compress_debug): Likewise.
Alan Modra [Tue, 2 Sep 2025 12:15:39 +0000 (21:45 +0930)]
tidy tilegx and tilepro MAX_MEM_FOR_RS_ALIGN_CODE
These weren't wrong, but should use the BUNDLE_SIZE macros, in case
they ever change.
* config/tc-tilegx.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEGX_BUNDLE_SIZE_IN_BYTES.
* config/tc-tilepro.h (MAX_MEM_FOR_RS_ALIGN_CODE): Use
TILEPRO_BUNDLE_SIZE_IN_BYTES.
Alan Modra [Tue, 2 Sep 2025 09:43:36 +0000 (19:13 +0930)]
visium MAX_MEM_FOR_RS_ALIGN_CODE
Commit 7ca6020a4e52 "tidy target HANDLE_ALIGN" didn't account for
the "fix" amount emitted by visium_handle_align. This didn't show up
as a problem due to frag alignment hiding the error, until I started
messing with struct frag.
Simon Marchi [Tue, 8 Jul 2025 20:54:45 +0000 (16:54 -0400)]
gdb/remote: call target_pre_inferior in remote_target::remote_add_inferior
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), and with the previous patch applied ("gdb/remote: use
scoped_restore_current_program_space in remote_unpush_target"), we get
this failure:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
When connecting to a remote that has one or more inferior already
running, the remote target (the GDB-side code) tries to re-use existing
GDB inferiors that are unused. The problem is that the program space of
the inferior that gets re-used unexpectedly has its solib_ops set.
I think that the problem is that when connecting to a remote target that
has multiple inferiors, target_pre_inferior only gets called for the
currently selected (client-side) inferior. It happens here:
#0 target_pre_inferior () at /home/smarchi/src/wt/amd/gdb/target.c:2454
#1 0x0000559c832a350a in target_preopen (from_tty=1) at /home/smarchi/src/wt/amd/gdb/target.c:2510
#2 0x0000559c82e1b8f1 in remote_target::open_1 (name=0x50200006eb58 ":2345", from_tty=1, extended_p=1) at /home/smarchi/src/wt/amd/gdb/remote.c:6171
#3 0x0000559c82e18a5d in extended_remote_target::open (name=0x50200006eb58 ":2345", from_tty=1) at /home/smarchi/src/wt/amd/gdb/remote.c:5446
#4 0x0000559c8329a43e in open_target (args=0x50200006eb58 ":2345", from_tty=1, command=0x512000072c40) at /home/smarchi/src/wt/amd/gdb/target.c:839
I think that target_pre_inferior should be called for the other
inferiors that gain execution as a result of connecting to the remote
target, to make sure inferior or program space-specific data from
previous executions gets cleared. target_pre_inferior is what clears
any previous solib_ops.
It is possible to observe the problem by adding this print in
target_pre_inferior:
printf (">>> target_pre_inferior called for inferior %d\n",
current_inferior ()->num);
Then, starting a gdbserver:
$ gdbserver --multi localhost:2345
Then, this gdb command that starts two remote inferiors, disconnects
(leaving gdbserver and the inferiors running), then reconnects:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote :2345' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect' \
-ex 'echo About to reconnect\n' \
-ex 'target extended-remote :2345'
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
Breakpoint 1 at 0x11fc: file /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c, line 50.
>>> target_pre_inferior called for inferior 1
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Breakpoint 1, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[New inferior 2]
Added inferior 2 on connection 1 (extended-remote :2345)
[Switching to inferior 2 [<null>] (<noexec>)]
Reading symbols from /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart...
>>> target_pre_inferior called for inferior 2
Starting program: /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart
Thread 2.1 "extended-remote" hit Breakpoint 1.2, main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
[Switching to inferior 1 [process 2591936] (/home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart)]
[Switching to thread 1.1 (Thread 2591936.2591936)]
#0 main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
Ending remote debugging.
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
We can see that target_pre_inferior is only called for inferior 1 when
reconnecting (after the "About to reconnect" message).
After adding the call to target_pre_inferior in remote_add_inferior, we
get (just the last bit):
About to reconnect
>>> target_pre_inferior called for inferior 1
Remote debugging using :2345
>>> target_pre_inferior called for inferior 1
>>> target_pre_inferior called for inferior 2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
(No debugging symbols found in /lib/x86_64-linux-gnu/libc.so.6)
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
main () at /home/smarchi/src/wt/amd/gdb/testsuite/gdb.server/extended-remote-restart.c:50
50 pid = fork ();
The duplicate calls to target_pre_inferior for inferior 1 are due to the
existing call in target_preopen. It might be possible to get rid of it:
with the call I added in remote_target::remote_add_inferior, I presume
it's now unnecessary for the remote target to have the call in
target_preopen as well. But since target_preopen is used by other
targets, I prefer to leave it there to be safe, for the moment. Calling
target_pre_inferior multiple times should not be a problem, as it should
be idempotent.
However, once I added that, test gdb.server/stop-reply-no-thread.exp
started failing, with this in the logs:
target remote localhost:2347
Remote debugging using localhost:2347
Remote 'g' packet reply is too long (expected 560 bytes, got 820 bytes): 000000... <truncated>
It became apparent that the new call to target_pre_inferior would wipe a
previously fetched target description. I fixed that by adding calls to
target_find_description in two callers of remote_add_inferior. I'm not
100% sure of what I'm doing here, but it seems somewhat correct that
when we map a remote inferior to an existing client-side inferior, we
wipe out any previous target description (which would have been left by
a previous execution) and fetch a new one.
The other call to remote_add_inferior is in
extended_remote_target::attach, where there is already a call to
target_find_description shortly after.
The issue is that remote_unpush_target uses
scoped_restore_current_inferior to save the context, which only restores
the current inferior on exit. But it then uses
switch_to_inferior_no_thread, which switches the inferior and the
program space. The program space is therefore left unrestored. This
can leave the current inferior and current program space out of sync.
With two inferiors, let's say we enter with current inferior == 1 and
current program space == 1. When calling switch_to_inferior_no_thread
for inferior 2, we set the current inferior to 2 and current program
space to 2. On exit, only the original inferior is restored, so we end
up with current inferior == 1 and current program space == 2.
The problem can be observed manually by starting two remote inferiors
and disconnecting while inferior 1 is selected:
Then, connecting top-gdb to that gdb, we see the inconsistency:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 2
When the test tries to connect to a remote target again, GDB maps the
remote inferior to inferior 1, but tries to set the solib_ops of program
space 2, which already has an solib_ops set, causing the internal error.
Fix this by using scoped_restore_current_program_space in addition to
scoped_restore_current_inferior. With this patch applied, we get:
(top-gdb) p current_inferior_.m_obj.num
$1 = 1
(top-gdb) p current_program_space.num
$2 = 1
With this patch, we then hit another internal error, fixed by the
following patch.
H.J. Lu [Mon, 1 Sep 2025 18:00:43 +0000 (11:00 -0700)]
readelf: Report if no GOT section found
Update "readelf --got-contents" to report if no GOT section found.
* readelf.c (process_got_section_contents): Report if no GOT
section found.
* testsuite/binutils-all/readelf-got.d: New file.
* testsuite/binutils-all/readelf.exp: Run readelf-got.
The apparent intent of the original code added in
https://sourceware.org/pipermail/binutils/2012-August/078044.html was
to emit an error message if the instruction was obsolete and only to
emit a deprecation warning if an error hadn't already been emitted.
However, when the insn has not yet been obsoleted, the code would
generate a warning with a (null) message body if the selected CPU was
'any'.
The previous fix for this bug was to remove the support for the
obsoletion message entirely, which was probably the wrong approach. A
better fix is to only call check_obsolete if obs_msg is non-null; we
can use this as a proxy for the instruction not being obsolete on any
architecture.
While we are here, fix an incorrect capitalization in the deprecation
message ('This' to 'this').
Pedro Alves [Fri, 29 Aug 2025 19:05:48 +0000 (20:05 +0100)]
Fix host_file_normalize_mingw
Tom de Vries ran the testsuite on msys2-ucrt64 with mount point map:
...
/bin C:/msys64/usr/bin
/c C:
/ C:/msys64
...
and ran into the problem that host_file_normalize didn't translate:
...
/home/user/gdb/build/gdb/testsuite/temp/n/x
...
into:
...
C:/msys64/home/user/gdb/build/gdb/testsuite/temp/n/x
...
The problem is that host_file_normalize_mingw mishandles a
file/directory under the root mount point. A simpler reproducer is
"/foo". If we add that as a test to
gdb.testsuite/mount-point-map.exp, we see:
For a mount point that ends in /, this line in
host_file_normalize_mingw:
} elseif {[string index $filename $mount_len] eq "/"} {
... is always false, because the character at $mount_len is the one
_after_ the slash.
Notice that the "/" mount point is the only one that ends in "/".
This is even if you try to create one explicitly with a trailing /.
On MSYS2:
$ mount c:/foo /foo/
mount: warning - /foo/ does not exist.
$ mount
C:/foo on /foo type ntfs (binary,user)
...
So fix this by special casing the "/" mount point.
And then... while playing with fixing this, I noticed I had done
something strange with this case:
if {[string length $filename] == $mount_len} {
return "$win_filename/"
The intent was to append the slash when the mount is a drive letter,
like 'cygpath -ma' does:
$ cygpath -ma /c
C:/
Other cases do not get a trailing slash:
$ cygpath -ma /c/foo
C:/foo
I think this is because on Windows, every drive letter has a current
directory, and really "C:" means "current directory of drive letter
C:", not "root of C:". Resolving it to "C:/" makes it unambiguous.
However, I mishandled that in a63213cd374d ('MSYS2+MinGW testing: Unix
<-> Windows path conversion'). The original version of that patch
when I posted it to the mailing list only supported drive mounts,
which turned out incorrect, and then I generalized it to work with all
mount points before it was merged. In the process, I inadvertently
made the code append the slash whenever the input filename matches a
mount exactly, any mount.
I also now noticed that TCL's "file normalize" on Linux always removes
the trailing slash, and since host_file_normalize is an abstraction
for it, I think host_file_normalize_mingw should do the same.
Likewise for duplicate slashes, "file normalize" gets rid of them.
Fix all this in host_file_normalize_mingw, and add corresponding tests
to gdb.testsuite/mount-point-map.exp.
I smoke tested this here with a few of the testcases that required
tweaking in the patch that added host_file_normalize, like
gdb.base/source-dir.exp and gdb.base/fullname.exp and they still pass.
Tom ran gdb.testsuite/mount-point-map.exp on both x86_64-linux and
msys2-ucrt64, and it passed in both cases.
x86/testsuite: Adjust unused FRED and MOVRS tests [PR33348]
The tests mentioned in PR33348 needs different care.
For FRED tests, we could simply remove them since there are
no operands and the tests are the same as AT&T Syntax.
For MOVRS tests, we allowed suffixes for AT&T suffixes although
we could tell the difference according to register operand to
align with legacy mov. Thus, the suffixes tests are needed for
AT&T Syntax while not needed for Intel Syntax. Adjust them
accordingly.
gas/ChangeLog:
PR ld/33348
* testsuite/gas/i386/x86-64-movrs-suffix.d: Describe the
test with more precise.
* testsuite/gas/i386/x86-64-movrs-suffix.s: Remove Intel
Syntax part.
* testsuite/gas/i386/x86-64.exp: Add MOVRS suffix tests.
* testsuite/gas/i386/x86-64-fred-intel.d: Removed.
* testsuite/gas/i386/x86-64-movrs-suffix-intel.d: Ditto.
Lulu Cai [Tue, 26 Aug 2025 09:19:47 +0000 (17:19 +0800)]
LoongArch: Fix incorrect display of FDEs address ranges when using objdump -Wf
When parsing FDEs in `.eh_frame` using `objdump -Wf`, it is necessary to
resolve `BFD_RELOC_LARCH_32_PCREL` to determine the address ranges of
the FDEs. Set the `pcrel_offset` field of `BFD_RELOC_LARCH_32_PCREL` to
help `objdump` correctly compute the address ranges of the FDEs.
Apply the same modification to BFD_RELOC_LARCH_64_PCREL.
Alan Modra [Mon, 1 Sep 2025 01:30:17 +0000 (11:00 +0930)]
Re: readelf: Add --got-contents option
The cris ld testsuite uses readelf -a. The extra output now means
that a number of tests fail. Fix that by not using -a, but rather
the options corresponding to output checked in the dump files.
* testsuite/ld-cris/tls-local-63.d: Replace -a option with -r -s.
Remove now unnecessary #... and superfluous unwind message.
* testsuite/ld-cris/tls-local-64.d: Likewise.
* testsuite/ld-cris/tls-und-38.d: Likewise.
* testsuite/ld-cris/tls-und-42.d: Likewise.
* testsuite/ld-cris/tls-und-46.d: Likewise.
* testsuite/ld-cris/tls-und-50.d: Likewise.
* testsuite/ld-cris/weakref3.d: Replace -a with -S -r -s, and
remove unwind message.
* testsuite/ld-cris/weakref4.d: Likewise.
Tom de Vries [Mon, 1 Sep 2025 07:07:11 +0000 (09:07 +0200)]
[gdb] Fix handling of aborted inferior call
PR gdb/33069 reports the following behavior:
...
$ gdb -q ls -ex starti -ex "b *1"
Reading symbols from ls...
(No debugging symbols found in ls)
Starting program: /usr/bin/ls
Program stopped.
0x00007ffff7fe4f00 in _start () from /lib64/ld-linux-x86-64.so.2
Breakpoint 1 at 0x1
(gdb) p (int)strlen("abc")
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x1
Command aborted.
An error occurred while in a function called from GDB.
Evaluation of the expression containing the function
(malloc@plt) will be abandoned.
When the function is done executing, GDB will silently stop.
[1]+ Stopped gdb -q ls -ex starti -ex "b *1"
$ fg
gdb -q ls -ex starti -ex "b *1"
(gdb)
...
with gdb being unresponsive to further input.
PR gdb/33068 reports a similar problem, but using gdbserver, and in that case
gdb doesn't go into the background, but is likewise unresponsive.
This is a regression since commit b1c0ab20809 ("gdb: avoid double stop after
failed breakpoint condition check"), and consequently since release gdb 14.1.
The commit changed this in run_inferior_call:
...
if (current_ui->prompt_state == PROMPT_BLOCKED)
- current_ui->unregister_file_handler ();
- else
- current_ui->register_file_handler ();
+ {
+ if (call_thread->thread_fsm ()->finished_p ())
+ async_disable_stdin ();
+ else
+ async_enable_stdin ();
+ }
...
which means current_ui->register_file_handler is no longer called in the
current_ui->prompt_state == PROMPT_NEEDED case.
Fix this by:
- restoring this behavior, fixing the unresponsiveness, and
- adding target_terminal::ours alongside it, fixing the problem that gdb goes
into the background.
Add a new test-case gdb.base/infcall-failure-2.exp, a regression test for the
unresponsiveness issue. The problem of gdb going into the background did not
reproduce in the test-case.
Tested on x86_64-linux.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33068
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33069
Rainer Orth [Sun, 31 Aug 2025 10:14:36 +0000 (12:14 +0200)]
ld: Move Solaris/sparcv9 TEXT_START_ADDR to elf64_sparc_sol2.sh
While looking at the Solaris versions of the program header p_vaddr and
p_align values of the text and data segments, I noticed that the
Solaris/sparcv9 version of TEXT_START_ADDR is defined in a shared file.
Since there's a Solaris/sparcv9 specific file now
(ld/emulparams/elf64_sparc_sol2.sh), it seems cleaner to move it there.
Tested on {sparcv9,sparc}-sun-solaris2.11 and
{sparc64,sparc}-unknown-linux-gnu.
Simon Marchi [Fri, 29 Aug 2025 20:05:27 +0000 (16:05 -0400)]
gdb/solib-svr4: update default debug base in svr4_solib_ops::current_sos
Commit d33a66a31134 ("gdb/solib-svr4: fix wrong namespace id for dynamic
linker") regressed test gdb.base/break-probes.exp with the native-gdbserver
board:
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/break-probes.exp ...
FAIL: gdb.base/break-probes.exp: run til our library loads (the program exited)
FAIL: gdb.base/break-probes.exp: call (int) foo(23)
In the logs, we see this:
Stopped due to shared library event:
Inferior unloaded target:/lib64/ld-linux-x86-64.so.2
Inferior loaded target:/lib64/ld-linux-x86-64.so.2
When we should see this:
Stopped due to shared library event (no libraries added or removed)
In the unexpected output, GDB claims that the inferior unloaded and then
loaded the dynamic linker. This is obviously not true.
Commit d33a66a31134 changed the svr4_same function to consider the debug
bases the solibs come from. Two solibs with the same inferior address but
different debug base (such as the multiple solibs representing the dynamic
linker in all the namespaces) now compare unequal.
That commit also introduced a mechanism to update the debug base of an
existing solib (more precisely, field lm_info_svr4::debug_base) when that
value becomes known. The solib for the dynamic linker view in the default
namespace starts with a debug base of 0, and is then changed to have the
real debug base address later on.
With the particular code path taken when connecting to a remote target,
nothing triggers the update of the debug base of the dynamic linker solib
initially created with a debug base of 0. So when
svr4_solib_ops::current_sos returns a list with an solib for the dynamic
linker with the real debug base value, the core sees this as an unload and
a load.
This happens specifically when debuggin remotely, because,
svr4_solib_ops::current_sos_direct takes the "using_xfer" branch, which
doesn't do any svr4_solib_ops::default_debug_base call. In local, we don't
take that branch, which leads us to a call to default_debug_base.
The way I propose to fix it is to add a call to
svr4_solib_ops::default_debug_base at the beginning of
svr4_solib_ops::current_sos. The rationale to put it there is that if the
core is requesting a fresh list of libraries, and then compare that list
with what it had previously, then we better make sure that the core's list
has received the debug base update, if one is needed.
Change-Id: If09c5a7b3d956e18d4b9514466226267c85f12a6 Approved-by: Kevin Buettner <kevinb@redhat.com>
The GCSPR is almost always updated implicitly by the hardware, so the
compiler doesn't generate DWARF unwind information for it. Therefore add
an unwinding function that calculates the value of the GCSPR in the
previous frame based on its value in this frame. Some sanity checking is
done by confirming that the calculated value is within a Guarded Control
Stack memory area.
This function is the same as amd64_linux_dwarf2_prev_ssp, written by
Christina Schimpe to unwind Intel's SSP register.
The gdb.arch/aarch64-gcs-return.exp testcase is lightly adapted from
gdb.arch/amd64-shadow-stack-cmds.exp.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com>
GDB: aarch64-linux: Implement GCS support in displaced stepping
When doing displaced step on a branch and link instruction with the Guarded
Control Stack enabled, it's necessary to manually push and pop the GCS
entry for the function call since GDB writes a simple branch instruction
rather than a branch and link instruction in the displaced step buffer.
The testcase exercises GCS with displaced stepping by putting the
breakpoint on the bl instruction to force GDB to copy it to the
displaced stepping buffer. In this situation GDB needs to manually
manage the Guarded Control Stack.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com>
The signal frame can have a GCS context, so teach GDB how to use it.
Also, there's a new SEGV sigcode when the inferior does an illegal
memory access in the Guarded Control Stack, so display a message when
that is the case.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com>
GDB, gdbserver: aarch64-linux: Initial Guarded Control Stack support
Add the org.gnu.gdb.aarch64.gcs feature with the GCSPR register, and the
org.gnu.gdb.aarch64.gcs.linux feature with "registers" to represent the
Linux kernel ptrace and prctl knobs that enable and lock specific GCS
functionality.
This code supports GCS only in Linux userspace applications, so the
GCSPR that is exposed is the one at EL0.
Also, support for calling inferior functions is enabled by adding an
implementation for the shadow_stack_push gdbarch method.
If for some reason a target description contains the
org.gnu.gdb.aarch64.gcs feature but not the
org.gnu.gdb.aarch64.gcs.linux feature then GCS support is disabled and
GDB continues the debugging session. Features that need GCS
support (for example, calling inferior functions) will not work and the
inferior will get a segmentation fault signal instead. There's a
testcase for this scenario but it only checks the native debugging case,
even though in practice this problem would only occur in remote
debugging with a broken stub or gdbserver. I tested manually with a
gdbserver hacked to send a broken target description and it worked as
described.
Testcases gdb.arch/aarch64-gcs.exp, gdb.arch/aarch64-gcs-core.exp and
gdb.arch/aarch64-gcs-wrong-tdesc.exp are included to cover the added
functionality.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com> Approved-By: Luis Machado <luis.machado@arm.com>
Simon Marchi [Thu, 28 Aug 2025 15:10:51 +0000 (11:10 -0400)]
gdb/objfiles: use filtered_iterator as objfile::section_iterator
objfile::section_iterator looks like a good candidate to be implemented
with filtered_iterator. Following the enhancements to filtered_iterator
in the previous patch, it's pretty straighforward.
I removed the non-const version of objfile::sections, because it didn't
seem useful to have the two methods returning the exact same type and
value. Having just the const version achieves the same thing.
Change-Id: I2f29c2fb3f95605cb816cc1ff8935c10e0496052 Approved-By: Tom Tromey <tom@tromey.com>
- Give filtered_iterator a constructor where the caller provides
already constructed begin and end iterators. filtered_iterator
currently assumes that default-constructing a BaseIterator will
produce a valid "end" iterator. This is not the case if BaseIterator
is a pointer. The caller needs to pass in the end of the array /
region to iterate on as the end.
The compiler would complain that it's not possible to apply `::` to
type `BaseIterator` (aka `Foo *`). Use std::iterator_traits to fix
it [1].
- Similarly, the compiler would complain about the use of
`BaseIterator::operator*` in the return type of
`filtered_iterator::operator*`. Fix this by using `decltype(auto)`
as the return type. This lets the compiler deduce the return type
from the return statement. Unlike `auto`, `decltype(auto)` perfectly
preserves the "cvref-ness" of the deduced return type. If the return
expression yields a `Foo &`, then the function will return a `Foo &`
(which is what we want), whereas it would return a `Foo` if we used
just `auto`.
Improve the filtered_iterator unit tests to run the same tests but with
pointers as iterators. Because the filtered_iterator objects are
initialized differently in the two scenarios, I chose to copy the
existing code and adapt it. It would probably be possible to add a
layer of abstraction to avoid code duplication, but it would end up more
complicated and messy. If we ever add a third scenario, we can revisit
that.
projects / thirdparty / binutils-gdb.git / log
