| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
I noticed on M1 aarch64-linux that test-case
gdb.testsuite/gdb-caching-proc-consistency.exp took a long time.
I saw lack of progress in gdb.log for proc allow_aarch64_gcs_tests.
This gdb_expect only handles the case that gcs support is detected:
...
gdb_expect {
-re ".*$inferior_exited_re normally.*${gdb_prompt} $" {
verbose -log "\n$me: gcs support detected"
set allow_gcs_tests 1
}
}
...
but in my case, I get:
...
(gdb) run ^M
Starting program: allow_aarch64_gcs_tests.x ^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Inferior 1 (process 3336556) exited with code 01]^M
(gdb)
...
so the gdb_expect times out quietly, taking 10 seconds.
In the test-case, it does so 11 times.
Fix this by adding a gdb_expect clause handling the "with code 01" case.
Tested on aarch64-linux.
PR testsuite/33378
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33378
|
|
Change-Id: Ifcf80faa240c7c235bfea4ddc79f0d6c39858c5e
|
|
On platforms where long is 32 bits, this change fixes a build failure:
/home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c: In function ‘const target_desc* aarch64_linux_core_read_description(gdbarch*, target_ops*, bfd*)’:
/home/linux/arm/gdb/src/gdb/arch/aarch64-gcs-linux.h:27:24: error: left shift count >= width of type [-Werror=shift-count-overflow]
27 | #define HWCAP_GCS (1UL << 32)
| ~~~~^~~~~
/home/linux/arm/gdb/src/gdb/aarch64-linux-tdep.c:1714:47: note: in expansion of macro ‘HWCAP_GCS’
1714 | features.gcs = features.gcs_linux = hwcap & HWCAP_GCS;
| ^~~~~~~~~
Suggested-by: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33372
|
|
After the previous commit, the changes to gdb.dap/scopes.exp from the
commit:
commit 63b862be762e1e6e7ce667c6b4a1a3dd79939bf4
Date: Fri Mar 29 16:38:50 2019 +0100
gdb, gdbserver: Add support of Intel shadow stack pointer register.
Are no longer needed, the test will now happily handle the shadow
stack pointer being unavailable.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
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.
There's also a test.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33345
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
|
|
Make sure the function bails out early if CURRENT_PC is reached, to
avoid the call to amd64_analyze_stack_alloc.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
|
Make sure the function bails out early if CURRENT_PC is reached, to
avoid the call to amd64_analyze_register_saves.
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
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>
|
|
The "Bss=" part of the qOffsets response is documented as being
optional, but gdb in fact requires it. This patch fixes the bug.
I couldn't find a straightforward way to test this. gdbserver does
send 'Bss=' -- but this code is only enabled for a fairly specific
setup:
#if (defined(__UCLIBC__) \
&& defined(HAS_NOMMU) \
&& defined(PT_TEXT_ADDR) \
&& defined(PT_DATA_ADDR) \
&& defined(PT_TEXT_END_ADDR))
#define SUPPORTS_READ_OFFSETS
#endif
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>
|
|
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.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
Fix clean_restart <absolute filename> in gdb.arch/*.exp.
The fixed test-cases are supported on archs sh, ia64, mips, pa and sparc.
I haven't tested these.
|
|
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.
|
|
Fix clean_restart <absolute filename> in gdb.arch/thumb*.exp.
Likewise in test-case gdb.arch/pr25124.exp.
Tested on arm-linux, target boards unix/-marm and unix/-mthumb.
|
|
Fix clean_restart <absolute filename> in gdb.arch/arm*.exp.
Tested on:
- arm-linux, target boards unix/-marm and unix/-mthumb
- aarch64-linux
|
|
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
...
|
|
Fix clean_restart <absolute filename> in gdb.arch/i386*.exp.
Tested on x86_64-linux, with target board unix/-m32 and gcc 15.
The only unsupported test-case is gdb.arch/i386-avx512.exp, which isn't
changed by this commit.
|
|
Fix clean_restart <absolute filename> in gdb.arch/amd64*.exp.
Tested on x86_64-linux, with kernel version 6.16.3.
The only unsupported test-case is gdb.arch/amd64-lam.exp, which isn't changed
by this commit.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.ada.
Tested on x86_64-linux with gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.compile.
Tested on x86_64-linux, fedora rawhide.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.cp.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.debuginfod.
Tested on x86_64-linux.
|
|
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.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.dwarf2.
Tested on x86_64-linux using gcc-14.
Tested these test-cases on x86_64-linux with target board unix/-m32:
- gdb.dwarf2/valop.exp
- gdb.dwarf2/callframecfa.exp
- gdb.dwarf2/implptr.exp
- gdb.dwarf2/watch-notconst.exp
- gdb.dwarf2/pieces.exp
- gdb.dwarf2/pieces-optimized-out.exp
Tested these test-cases on x86_64-linux with target board fission-dwp:
- gdb.dwarf2/dwp-symlink.exp
- gdb.dwarf2/dwp-sepdebug.exp
Tested test-case gdb.dwarf2/gdb-index-tilde.exp on x86_64-linux by disabling a
too strict home directory check, see PR testsuite/33364.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.fortran.
Tested on x86_64-linux, with gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.gdb.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.guile.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.linespec.
Tested on x86_64-linux.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.mi.
Tested on x86_64-linux.
Also tested test-case gdb.mi/mi-dprintf.exp with target boards
native-gdbserver and native-extended-gdbserver.
Since test-case gdb.mi/mi-regs.exp requires istarget "sparc-*-*", I didn't
test the trivial change in that test-case.
|
|
Fix mi_clean_restart <absolute filename> in the test-cases in gdb.trace.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
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>
|
|
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>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.multi.
Tested on x86_64-linux.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.objc.
Tested on x86_64-linux, using 'lappend options "nowarnings"' in
gdb_compile_shlib_pthreads. See also PR testsuite/24807.
|
|
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.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33363
|
|
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>
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.opt.
Tested on x86_64-linux using gcc 14.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.perf.
Tested on x86_64-linux using check-perf.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.python.
Tested on x86_64-linux.
|
|
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"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 0, follow-child 1: disconnect
target extended-remote localhost:2348
Remote debugging using localhost:2348
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
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.
Change-Id: I85426bfff286a67d5fb74bbf978df80060ee6deb
|
|
Since commit 3cb6bc13e328 ("gdb/progspace: add solib_ops pointer in
program_space"), this fails with an internal error:
$ make check TESTS="gdb.server/extended-remote-restart.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
In gdb.log:
(gdb) PASS: gdb.server/extended-remote-restart.exp: kill: 1, follow-child 0: disconnect
target extended-remote localhost:2347
Remote debugging using localhost:2347
/home/smarchi/src/binutils-gdb/gdb/progspace.h:240: internal-error: set_solib_ops: Assertion `m_solib_ops == nullptr' failed.
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:
$ ./gdb -nx --data-directory=data-directory -q \
-ex 'set sysroot /' \
-ex 'target extended-remote | gdbserver --multi --once -' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'set remote exec-file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'b main' \
-ex r \
-ex 'add-inferior' \
-ex 'inferior 2' \
-ex 'file /home/smarchi/build/wt/amd/gdb/testsuite/outputs/gdb.server/extended-remote-restart/extended-remote-restart' \
-ex 'run' \
-ex 'inferior 1' \
-ex 'disconnect'
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.
Change-Id: If916f581a223d6611f7f23a9cbbf1825d2cdd0ba
Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
|
|
Fix clean_restart <absolute filename> in the test-case in gdb.replay.
Tested on x86_64-linux, with target boards unix, native-gdbserver and
native-extended-gdbserver.
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.reverse.
Tested on:
- x86_64-linux, target boards unix and unix/-m32
- aarch64-linux
- ppc64le-linux
- s390x-linux
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.rocm.
Since these test-cases are unsupported for me, do the simple substitution:
...
clean_restart $binfile
->
clean_restart
gdb_load $binfile
...
|
|
Fix clean_restart <absolute filename> in the test-cases in gdb.server.
Tested on x86_64-linux.
|
