| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
target board native-gdbserver, we run into:
...
(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
ERROR: gdbserver does not support attach 4827 without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
(procedure "gdb_test_multiple" line 51)
invoked from within
"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
-re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
# Not permitte..."
(procedure "gdb_real__can_spawn_for_attach_1" line 27)
invoked from within
"gdb_real__can_spawn_for_attach_1"
...
The problem is that:
- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
designed to be called only from that function, and
- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
can_spawn_for_attach_1 directly.
Fix this by copying the early-outs from can_spawn_for_attach to
can_spawn_for_attach_1.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
The TUI can't really work properly with new-ui, at least not as
currently written. This patch changes new-ui to reject an attempt.
Attempting to make a DAP ui this way is also now rejected.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
When printing complaints with one of the execs from test-case
gdb.dwarf2/macro-source-path.exp, we run into:
...
$ gdb -q -batch \
-iex "set complaints 100" \
macro-source-path-clang14-dw4-absolute-cwd-32 \
-ex "p main"
During symbol reading: debug info runs off end of .debug_macro section \
[in module macro-source-path-clang14-dw4-absolute-cwd-32]
$1 = {int ()} 0x4004b7 <main>
...
and readelf complains more specifically:
...
Contents of the .debug_macro section:
Offset: 0
Version: 5
Offset size: 4
Offset into .debug_line: 0xe3
DW_MACRO_define - lineno : 0 macro : ONE 1
DW_MACRO_define_strp - lineno : 0 macro : THREE 3
DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c
DW_MACRO_define - lineno : 1 macro : TWO 2
DW_MACRO_end_file
readelf: Error: .debug_macro section not zero terminated
...
Fix this by adding the missing terminator in Dwarf::_macro_unit.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The 'univeral_compile_options' in gdb.exp file only verifies the support
of '-fdiagnostics-color=never' for the "C" source file. So while running
tests with assembly source file (.s), many of them are not able to run
on icx/clang compilers because '-fdiagnostics-color=never' option is not
supported. This problem is not seen for the ".S" assembly source files so
these files are not handled separately. After this change, this function
is split into multiple functions to check the support for different type
of sources individually.
Before this change, in the case of clang and ICX compiler, this error is
shown for assembly source files (.s):
'''
icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o
amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300)
icx: warning: argument unused during compilation: '-fdiagnostics-color=never'
[-Wunused-command-line-argument]
gdb compile failed, icx: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare
'''
Similarly this error is shown for the clang compiler:
'''
clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0
-o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s
clang: warning: argument unused during compilation:
'-fdiagnostics-color=never' [-Wunused-command-line-argument]
'''
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Add support for DW_MACRO_define_strp in dwarf assembly, and use it in
test-case gdb.dwarf2/macro-source-path.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
C++14 allows the use of the apostrophe as a numeric separator; that
is, "23000" and "23'000" represent the same number. This patch
implements this for gdb's C++ parser and the C++ name canonicalizer.
I did this unconditionally for all C variants because I think it's
unambiguous.
For the name canonicalizer, there's at least one compiler that can
emit constants with this form, see bug 30845.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
While working on another patch I needed to pass -Wl,-soname,NAME as a
compiler flag. I initially looked for other tests that did this, and
found a few examples, so I copied what they did.
But when I checked the gdb.log file I noticed that we were actually
getting -Wl,-soname passed twice.
I tracked the repeated option to 'proc gdb_compile_shlib_1' in
lib/gdb.exp. It turns out that we always add -Wl,-soname when
compiling a shared library.
Here's an example of a build command from gdb.base/prelink.exp:
builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \
/tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \
-fdiagnostics-color=never -shared -g \
-Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \
-o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so
Notice that '-Wl,-soname,prelink.so' is repeated.
I believe that all of the places where tests add '-Wl,-soname,NAME' as
a build option, are unnecessary.
In this commit I propose we remove them all.
As part of this change I've switched from calling gdb_compile_shlib
directly, to instead call build_executable and adding the 'shlib'
flag.
I've tested with gcc and clang and see no changes in the test results
after this commit. All the compile commands still have -Wl,-soname
added, but now it's only added once, from within lib/gdb.exp.
There should be no change in what is tested after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge"
parameter from destructors of classes with no virtual bases; Linaro's CI
informed me that the gdb testsuite needs to be adjusted to match.
Teested against GCC 13.2 and GCC 15 trunk.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide
container, I run into:
...
temp/$pid/static-libc.c: In function 'main':
temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function
returning void [-Wreturn-mismatch]
2 | void main (void) { return 0; }
| ^
...
UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link
...
Fix this by changing the return type to int.
Tested on x86_64-linux.
|
|
The DAP spec allows a number of attributes on the resulting
instructions that gdb currently does not emit. A user requested some
of these, so this patch adds the 'symbol', 'line', and 'location'
attributes. While the spec lets the implementation omit 'location' in
some cases, it was simpler in the code to just always emit it, as then
no extra tracking was needed.
|
|
Bernd reported that when testing with riscv-unknown-elf target using
the simulator, before commit c7a2ee649115 ("gdb_is_target_native ->
gdb_protocol_is_native"), he had:
PASS: gdb.base/load-command.exp: probe for target native
PASS: gdb.base/load-command.exp: check initial value of the_variable
PASS: gdb.base/load-command.exp: manually change the_variable
PASS: gdb.base/load-command.exp: check manually changed value of the_variable
PASS: gdb.base/load-command.exp: reload: re-load binary
PASS: gdb.base/load-command.exp: reload: check initial value of the_variable
and now:
UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command
The problem is that the sim board/config isn't setting gdb_protocol
anywhere, so gdb_protocol_is_native returns true.
This commit fixes it by making gdb/testsuite/config/sim.exp set
gdb_protocol to "sim".
Reported-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Tested-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a
|
|
Currently, when a user tries to list the current location, there are 2
different error messages that can happen, either:
(gdb) list .
No symbol table is loaded. Use the "file" command.
or
(gdb) list .
No debug information available to print source lines.
The difference here is if gdb can find any symtabs at all or not, which
is not something too important for end-users - and isn't informative at
all. This commit changes it so that the error always says that there
isn't debug information available, with these two variants:
(gdb) list .
Insufficient debug info for showing source lines at current PC (0x55555555511d).
or
(gdb) list .
Insufficient debug info for showing source lines at default location.
The difference now is if the inferior has started already, which is
controlled by the user and may be useful.
Unfortunately, it isn't as easy to differentiate if the symtab found for
other list parameters is correct, so other invocations, such as "list +"
still retain their original error message.
Co-Authored-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because
all_objfiles_removed triggers tui_display_main").
When building with address sanitizer, and reverting the commit it triggers the
heap-use-after-free.
Tested on aarch64-linux.
PR symtab/31697
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697
|
|
In AIX when a thread exits we were not showing that a thread exit event happened
and GDB continued to keep the terminated threads.
If we have terminated threads then the UI on info threads command will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o)
2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.)
If we see the frame is not getting displayed correctly.
The reason for the same is that in AIX we were not managing thread states. In particular we do not know
when a thread terminates.
The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit.
This patch is a fix to the same.
Also certain UI is changed.
On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information.
[New Thread 258 (tid 32178533)]
[New Thread 515 (tid 30343651)]
[New Thread 772 (tid 33554909)]
[New Thread 1029 (tid 24969489)]
[New Thread 1286 (tid 18153945)]
[New Thread 1543 (tid 30736739)]
[Thread 258 (tid 32178533) exited]
[Thread 515 (tid 30343651) exited]
[Thread 772 (tid 33554909) exited]
[Thread 1029 (tid 24969489) exited]
[Thread 1286 (tid 18153945) exited]
[Thread 1543 (tid 30736739) exited]
and info threads will look like
(gdb) info threads
Id Target Id Frame
* 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o)
Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well.
|
|
The code in gdb.base/watchpoint-running.exp that is trying to skip
testing with hardware watchpoints also skips testing with software
watchpoints if hardware watchpoints aren't supported by the target.
This fixes it.
Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba
|
|
Remove accidentally leftover commented-out line from
gdb.base/watchpoint-running.exp.
Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697
|
|
A recent commit refactored with_rocm_gpu_lock:
commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e
Date: Sat May 4 10:41:09 2024 +0200
[gdb/testsuite] Factor out proc with_lock
Factor out proc with_lock from with_rocm_gpu_lock, and move required procs
lock_file_acquire and lock_file_release to lib/gdb-utils.exp.
This causes regressions in gdb.rocm/*.exp (as well as in downstream
rocgdb). The issue can be reproduced in the following minimal test:
load_lib rocm.exp
set foo hello
with_rocm_gpu_lock {
verbose -logs $foo
}
The issue is that the body to execute under the lock is executed in the
context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of
in the context of the "original" caller.
This patch adjusted with_rocm_gpu_lock to account for the new extra
frame in the call stack between the caller of with_rocm_gpu_lock and
where the code execution is triggered.
Approved-By: Tom de Vries <tdevries@suse.de>
Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe
|
|
When running the testsuite on a system with kernel.yama.ptrace_scope set to 1,
we run into attach failures.
Fix this by recognizing "ptrace: Operation not permitted" in
can_spawn_for_attach.
Tested on aarch64-linux and x86_64-linux.
Approved-By: Pedro Alves <pedro@palves.net>
|
|
In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I
introduced the behaviour that even though we have:
...
(gdb) p *a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
we get:
...
(gdb) p (char)*a_loc ()
$1 = 97 'a'
...
In other words, the unknown return type of a_loc is inferred from the cast,
effectually evaluating:
...
(gdb) p (char)*(char *)a_loc ()
...
This is convient for the case that errno is defined as:
...
#define errno (*__errno_location ())
...
and the return type of __errno_location is unknown but the macro definition is
known, such that we can use:
...
(gdb) p (int)errno
...
instead of
...
(gdb) p *(int *)__errno_location ()
...
However, as Pedro has pointed out in post-commit review [1], this makes it
harder to reason about the semantics of an expression.
For instance, this:
...
(gdb) p (long long)*a_loc ()"
...
would be evaluated without debug info as:
...
(gdb) p (long long)*(long long *)a_loc ()"
...
but with debug info as:
...
(gdb) p (long long)*(char *)a_loc ()"
...
Fix this by instead simply erroring out for this case:
...
(gdb) p (char)*a_loc ()
'a_loc' has unknown return type; cast the call to its declared return type
...
Tested on x86_64-linux.
Approved-By: Pedro Alves <pedro@palves.net>
[1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html
|
|
Make target check//% is the gdb variant of a similar gcc make target [1].
When running tests using check//%:
...
$ cd build/gdb
$ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp
...
we get:
...
$ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum
2427
$ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum
2423
...
The problem is that there are two portnum files used in parallel.
Fix this by:
- creating a common lockdir build/gdb/testsuite.lockdir for make target
check//%,
- passing this down to the runtests invocations using variable GDB_LOCK_DIR,
and
- using GDB_LOCK_DIR in lock_dir.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31632
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632
[1] https://gcc.gnu.org/install/test.html
|
|
When instrumenting get_portnum using:
...
puts "PORTNUM: $res"
...
and running:
...
$ cd build/gdb
$ make check-parallel -j2 TESTS=gdb.server/*.exp
...
we run into:
...
Running gdb.server/abspath.exp ...
PORTNUM: 2345
...
and:
...
Running gdb.server/bkpt-other-inferior.exp ...
PORTNUM: 2345
...
This is because the test-cases are run in independent runtest invocations.
Fix this by handling the parallel case in get_portnum using:
- a file $objdir/cache/portnum to keep the portnum variable, and
- a file $objdir/cache/portnum.lock to serialize access to it.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The lock directory returned by lock_dir is currently $objdir.
It seems possible to leave a stale lock file that blocks progress in a
following run.
Fix this by using a directory that is guaranteed to be initially empty when
using GDB_PARALLEL, like temp or cache.
In gdb/testsuite/README I found:
...
cache in particular is used to share data across invocations of runtest
...
which seems appropriate, so let's use cache for this.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In lib/rocm.exp we have:
...
set gpu_lock_filename $objdir/gpu-parallel.lock
...
This decides both the lock file name and directory.
Factor out a new proc lock_dir that decides on the directory, leaving just:
...
set gpu_lock_filename gpu-parallel.lock
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Factor out proc with_lock from with_rocm_gpu_lock, and move required procs
lock_file_acquire and lock_file_release to lib/gdb-utils.exp.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When instrumenting get_portnum using:
...
puts "PORTNUM: $res"
...
and running:
...
$ cd build/gdb
$ make check TESTS=gdb.server/*.exp
...
we get:
...
Running gdb.server/target-exec-file.exp ...
PORTNUM: 2345
Running gdb.server/stop-reply-no-thread-multi.exp ...
PORTNUM: 2345
PORTNUM: 2346
PORTNUM: 2347
PORTNUM: 2348
PORTNUM: 2349
PORTNUM: 2350
...
So, while get_portnum does return increasing numbers in a single test-case, it
restarts at each test-case.
This is a regression since the introduction of persistent globals.
Fix this by using "gdb_persistent_global portnum", such that we get:
...
Running gdb.server/target-exec-file.exp ...
PORTNUM: 2345
Running gdb.server/stop-reply-no-thread-multi.exp ...
PORTNUM: 2346
PORTNUM: 2347
PORTNUM: 2348
PORTNUM: 2349
PORTNUM: 2350
PORTNUM: 2351
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In gdbserver_start, we have some code that determines what port number to use:
...
# Port id -- either specified in baseboard file, or managed here.
if [target_info exists gdb,socketport] {
set portnum [target_info gdb,socketport]
} else {
# Bump the port number to avoid conflicts with hung ports.
incr portnum
}
...
Factor this out into a new proc get_portnum.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On Cygwin, supposely single-threaded programs are always
multi-threaded, due to the extra threads spawned by the Cygwin
runtime. Because of that, any gdb_continue_to_end call that doesn't
specify "allow_extra" fails, like so:
(gdb) PASS: gdb.base/langs.exp: show language at main
continue
Continuing.
[Thread 16140.0x1fbc exited with code 0]
[Thread 16140.0x2458 exited with code 0]
[Thread 16140.0x3494 exited with code 0]
[Inferior 1 (process 16140) exited normally]
(gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited)
Similarly, with this simple program compiled with MinGW:
$ cat ~/sleeper.c
#include <windows.h>
int main ()
{
Sleep (2000);
return 0;
}
and with a MinGW GDB, I see:
(gdb) start
...
(gdb) info threads
Id Target Id Frame
* 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5
2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) c
Continuing.
[Thread 15292.0x3850 exited with code 0]
[Inferior 1 (process 15292) exited normally]
(gdb)
This commit adjusts gdb_continue_to_end to expect the thread exited
messages, on Cygwin and MinGW.
Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
There's a pattern of using:
...
set saved_gdbflags $GDBFLAGS
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
set GDBFLAGS $saved_gdbflags
...
Simplify this by using save_vars:
...
save_vars { GDBFLAGS } {
set GDBFLAGS "$GDBFLAGS ..."
<do something with GDBFLAGS>
}
...
Tested on x86_64-linux.
|
|
INTERNAL_GDBFLAGS contains:
- -quiet
- -iex "set width 0"
- -iex "set height 0"
There are test-cases that add these once more.
Clean this up.
Tested on x86_64-linux.
PR testsuite/31649
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649
|
|
In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added
-q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS
example in gdb/testsuite/README.
Fix this by adding the -q there as well.
|
|
Consider a test-case compiled without debug info, containing:
...
char a = 'a';
char *
a_loc (void)
{
return &a;
}
...
We get:
...
(gdb) p (char)*a_loc ()
Cannot access memory at address 0x10
...
There's a bug in unop_ind_base_operation::evaluate that evaluates
"(char)*a_loc ()" the same as:
...
(gdb) p (char)*(char)a_loc ()
Cannot access memory at address 0x10
...
Fix this by instead evaluating it the same as:
...
(gdb) p (char)*(char *)a_loc ()
$1 = 97 'a'
...
Tested on x86_64-linux.
PR exp/31693
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693
|
|
In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a
workaround for PR gas/29517.
The problem is present in gas version 2.39, and fixed in 2.40, so the
workaround is only active for gas version == 2.39.
However, the problem in gas is only fixed for dwarf version >= 3, which
supports DW_TAG_unspecified_type.
Fix this by also activating the workaround for dwarf version == 2.
Tested on x86_64-linux.
Approved-by: Kevin Buettner <kevinb@redhat.com>
PR symtab/31689
https://sourceware.org/bugzilla/show_bug.cgi?id=31689
|
|
When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board
local-remote-host and target board remote-gdbserver-on-localhost, I get:
...
$ ls build/gdb/testsuite
cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile
outputs site.bak site.exp temp
...
The file compiler.i is there because get_compiler_info uses:
...
set ppout "$outdir/compiler.i"
...
The file is a temporary, and as such belongs in a temp dir. Fix this by using
standard_temp_file, moving the file to build/gdb/testsuite/temp/<pid>/compiler.i.
Tested on x86_64-linux.
|
|
After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have:
...
$ ls build/gdb/testsuite
cache config.status gdb.log lib outputs site.exp
config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp
...
The file gdb-index-nodebug.gdb-index doesn't belong there.
It happens to be there because we do:
...
set index_file ${testfile}.gdb-index
set cmd "save gdb-index [file dirname ${index_file}]"
...
which results in:
...
(gdb) save gdb-index .
...
The intention was possibly to use $binfile instead of $testfile, but using
that wouldn't work for remote host.
Fix this by using host_standard_output_file.
Tested on x86_64-linux.
|
|
Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove.
These functions are frequently optimized with specialized instructions
that favor larger memory access operations, so make sure GDB behaves
correctly in their presence.
There's a separate watched variable for each function so that the testcase
can test whether GDB correctly identified the watchpoint that triggered.
Also, the watchpoint is 28 bytes away from the beginning of the buffer
being modified, so that large memory accesses (if present) are exercised.
PR testsuite/31484
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
When testing with the native-extended-gdbserver board,
gdb.base/attach.exp shows a couple failures, like so:
Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ...
FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid
FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread)
From gdb.log:
builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build
/gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260
Don't know how to attach. Try "help target".
(gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid
There is a check for [isnative] to skip the test on anything but
target native, but that is the wrong check. native-extended-gdbserver
is "isnative". Fix it by using a gdb_protocol check instead.
Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768
Approved-By: Tom Tromey <tom@tromey.com>
|
|
After the previous patches, gdb_is_target_remote,
gdb_is_target_native, and mi_is_target_remote aren't used anywhere.
This commit eliminates them, along with now unnecessary helpers.
Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This is similar to the previous patch, but for gdb_protocol_is_remote.
gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
print target-stack", which is unnecessary when checking whether
gdb_protocol is "remote" or "extended-remote" would do. Checking
gdb_protocol is more efficient, and can be done before starting GDB
and running to main, unlike gdb_is_target_remote/mi_is_target_remote.
This adds a new gdb_protocol_is_remote procedure, and uses it in place
of gdb_is_target_remote/mi_is_target_remote throughout.
There are no uses of gdb_is_target_remote/mi_is_target_remote left
after this. Those will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gdb_is_target_native uses "maint print target-stack", which is
unnecessary when checking whether gdb_protocol is empty would do.
Checking gdb_protocol is more efficient, and can be done before
starting GDB and running to main, unlike gdb_is_target_native.
This adds a new gdb_protocol_is_native procedure, and uses it in place
of gdb_is_target_native.
At first, I thought that we'd end up with a few testcases needing to
use gdb_is_target_native still, especially multi-target tests that
connect to targets different from the default board target, but no,
actually all uses of gdb_is_target_native could be converted.
gdb_is_target_native will be eliminated in a following patch.
In some spots, we no longer need to defer the check until after
starting GDB, so the patch adjusts accordingly.
Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This fixes the same issue as the previous patch, but for "attach"
instead of "run".
If attaching to a process with "attach" (vAttach packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.
Here's an example:
On the GDB side:
...
(gdb) tar extended-remote :9999
...
Remote debugging using :9999
(gdb) attach 1
Attaching to process 1
Attaching to process 1 failed
(gdb)
On the GDBserver side:
$ gdbserver --once --multi :9999
Listening on port 9999
Remote debugging from host 127.0.0.1, port 37464
gdbserver: Cannot attach to process 1: Operation not permitted (1)
$ # gdbserver exited
This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vAttach, and continue
connected to GDB, waiting for other commands.
This commit fixes GDBserver by catching the error locally in
handle_v_attach.
Note we now let pid == 0 pass down to attach_inferior. That is so we
get a useful textual error message to report to GDB.
This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought
it would be useful to add a new testcase specifically for this
scenario, in case gdb.base/attach.exp is ever split and stops trying
to attach again after a failed attach, with the same GDB session.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554
Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393
Approved-By: Tom Tromey <tom@tromey.com>
|
|
If starting the inferior process with "run" (vRun packet) fails,
GDBserver throws an error that escapes all the way to the top level.
When an error escapes all the way like that, GDBserver interprets it
as a disconnection, and either goes back to waiting for a new GDB
connection, or exits, if --once was specified.
E.g., with the testcase program added by this commit, we see:
On GDB side:
...
(gdb) tar extended-remote :999
...
Remote debugging using :9999
(gdb) r
Starting program:
Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed
(gdb)
On GDBserver side:
$ gdbserver --once --multi :9999
Remote debugging from host 127.0.0.1, port 34344
bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied
bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied
gdbserver: During startup program exited with code 126.
$ # gdbserver exited
This is wrong, as we've connected with extended-remote/--multi.
GDBserver should just report an error to vCont, and continue connected
to GDB, waiting for other commands.
This commit fixes GDBserver by catching the error locally in
handle_v_run.
Change-Id: Ib386f267522603f554b52a885b15229c9639e870
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The patch:
From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Wed, 17 Apr 2024 12:55:00 +0200
Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses
I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main:
...
00000000004102c4 <end_of_sequence>:
4102c4: 52800000 mov w0, #0x0 // #0
4102c8: 9100c3ff add sp, sp, #0x30
4102cc: d65f03c0 ret
...
is not described by the line table:
...
<snip>
The regression failure on PowerPC is due to the change in file
dw2-lines.exp,
- DW_LNE_set_address bar_label_5
+ DW_LNE_set_address "$main_start + $main_len"
The label bar_label_5 is in function bar, not function main. The new
set address should have been $bar_start + $bar_len.
|
|
Factor the test for libc debug info out of gdb.base/relativedebug.exp to
a new procedure.
Also, change the "info sharedlibrary" test to explicitly detect when
libc has debug info.
Approved-by: Kevin Buettner <kevinb@redhat.com>
|
|
Consider the following test-case:
...
$ cat hello.c
int main()
{
printf("hello ");
#include "world.inc"
$ cat world.inc
printf("world\n");
return 0;
}
$ gcc -g hello.c
...
The line table for the compilation unit, consisting just of
function main, is translated into these two gdb line tables, one for hello.c
and one for world.inc:
...
compunit_symtab: hello.c
symtab: hello.c
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 3 0x400557 0x400557 Y
1 4 0x40055b 0x40055b Y
2 END 0x40056a 0x40056a Y
compunit_symtab: hello.c
symtab: world.inc
INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN
0 1 0x40056a 0x40056a Y
1 2 0x400574 0x400574 Y
2 3 0x400579 0x400579 Y
3 END 0x40057b 0x40057b Y
...
The epilogue of main starts at 0x400579:
...
400579: 5d pop %rbp
40057a: c3 ret
...
Now, say we have an epilogue_begin marker in the line table at 0x400579.
We won't find it using find_epilogue_using_linetable, because it does:
...
const struct symtab_and_line sal = find_pc_line (start_pc, 0);
...
which gets us the line table for hello.c.
Fix this by using "find_pc_line (end_pc - 1, 0)" instead.
Tested on x86_64-linux.
Co-Authored-By: Tom de Vries <tdevries@suse.de>
PR symtab/31622
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622
|
|
With test-case gdb.threads/threadcrash.exp using host board local-remote-host
and target board remote-gdbserver-on-localhost I run into:
...
(gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash
gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M
Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M
(gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore
UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file
...
The problem is that the gcore command tries to save a file on a remote host,
but the filename is a location on build.
Fix this by using host_standard_output_file.
Tested on x86_64-linux.
|
|
After installing glibc debuginfo, I ran into:
...
FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \
$thread_count == [llength $test_list]
...
This happens because the clause:
...
-re "^\r\n${hs}main$hs$eol" {
...
which is intended to match only:
...
#1 <hex> in main () at threadcrash.c:423^M
...
also matches "remaining" in:
...
#1 <hex> in __GI___nanosleep (requested_time=<hex>, remaining=<hex>) at \
nanosleep.c:27^M
...
Fix this by checking for "in main" instead.
Tested on x86_64-linux.
|
|
runto uses a hard-coded timeout of 30s in its invocation of gdb_expect.
This is normally fine, but for very a slow system (e.g., an emulator) it
may not be enough time for GDB to reach the intended breakpoint.
gdb_expect can obtain a timeout value from user-configurable variables
when it's not given one explicitly, so use that mechanism instead since
the user will have already adjusted the timeout variable to account for
the slow system.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
On SLE-11, with an older dejagnu version, I ran into:
...
Running gdb.ada/mi_prot.exp ...
UNRESOLVED: gdb.ada/mi_prot.exp: \
testcase aborted due to invalid command name: gdb_find_gnatmake
ERROR: tcl error sourcing gdb.ada/mi_prot.exp.
ERROR: invalid command name "gdb_find_gnatmake"
while executing
"::gdb_tcl_unknown gdb_find_gnatmake"
("uplevel" body line 1)
invoked from within
"uplevel 1 ::gdb_tcl_unknown $args"
(procedure "::unknown" line 5)
invoked from within
"gdb_find_gnatmake"
(procedure "gnatmake_version_at_least" line 2)
invoked from within
...
Proc gdb_find_gnatmake is actually a backup for find_gnatmake:
...
if {[info procs find_gnatmake] == ""} {
rename gdb_find_gnatmake find_gnatmake
...
so gnatmake_version_at_least should use find_gnatmake instead.
For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we
don't run into this error.
For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to
find_gnatmake, and we do run into the error.
It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it
seems something legitimate to use. Maybe we should use future_ or gdb_future_
prefix instead to make this more clear, but I've left that alone for now.
Fix this by:
- triggering the same error with a recent dejagnu by removing
gdb_find_gnatmake unless used (and likewise for other procs in future.exp),
and
- using find_gnatmake in gnatmake_version_at_least.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31647
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647
|
|
Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw
MemoryError in inferior.read_memory if malloc fails") introduced
AddressSanitizer allocation-size-too-big errors in the two test-cases
affected by this commit.
Fix this by suppressing the error in the two test-cases using
allocator_may_return_null=1.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html
|
|
Dummy CUs help detect errors and are very helpful. However, the DWARF
spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to
the header. This patch adds that.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
Approved-By: Tom de Vries <tdevries@suse.de>
Tested-By: Tom de Vries <tdevries@suse.de>
|
