| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The 'show user' command (which shows the definition of non-python/scheme
user defined commands) is currently missing a completer. This is
mentioned in PR 16238. Having one can improve the user experience.
In this commit I propose an implementation for such completer as well as
the associated tests.
Tested on x86_64 GNU/Linux.
All feedbacks are welcome.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16238
|
|
The test stops at <signal_handler called> which is the call to the handler
rather than in the handler as intended. This patch replaces the
gdb_test "$enter_cmd to handler" with a gdb_test_multiple test. The multiple
test looks for the stop at <signal_handler called>. If found, the command
is issued again. The test passes if gdb stops in the handler as expected.
(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler, step
from handler: continue to signal
stepi
<signal handler called>
1: x/i $pc
=> 0x7ffff7f80440 <__kernel_start_sigtramp_rt64>: bctrl
(gdb) stepi
handler (sig=551) at sigstep.c:32
32 {
1: x/i $pc
=> 0x10000097c <handler>: addis r2,r12,2
(gdb) PASS: gdb.base/sigstep.exp: stepi to handler, nothing in handler,
step from handler: stepi to handler
Patch has been tested on x86_64-linux and ppc64le-linux with no test failures.
|
|
On OBS I ran into:
...
(gdb) PASS: gdb.base/foll-vfork.exp: exit: \
vfork relations in info inferiors: continue to child exit
info inferiors^M
Num Description Connection Executable ^M
1 <null> foll-vfork-exit ^M
* 2 <null> foll-vfork-exit ^M
(gdb) I'm the proud parent of child #5044!^M
FAIL: gdb.base/foll-vfork.exp: exit: vfork relations in info inferiors: \
vfork relation no longer appears in info inferiors (timeout)
...
Fix this by removing the '$' anchor in the corresponding '$gdb_prompt $'
regexps.
Tested on x86_64-linux.
|
|
GDB hangs when doing this:
- launch inferior with multiple threads
- multiple threads hit some breakpoint(s)
- one breakpoint hit is presented as a stop, the rest are saved as
pending wait statuses
- "set scheduler-locking on"
- resume the currently selected thread (because of scheduler-locking,
it's the only one resumed), let it execute until exit
- GDB hangs, not showing the prompt, impossible to interrupt with ^C
When the resumed thread exits, we expect the target to return a
TARGET_WAITKIND_NO_RESUMED event, and that's what we see:
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] random_pending_event_thread: None found.
[Thread 0x7ffff7d9c700 (LWP 309357) exited]
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: -1.0.0 [process -1],
[infrun] print_target_wait_results: status->kind = no-resumed
[infrun] handle_inferior_event: status->kind = no-resumed
[infrun] handle_no_resumed: TARGET_WAITKIND_NO_RESUMED (ignoring: found resumed)
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: not requesting commit-resumed for target native, no resumed threads
[infrun] fetch_inferior_event: exit
The problem is in handle_no_resumed: we check if some other thread is
actually resumed, to see if we should ignore that event (see comments in
that function for more info). If this condition is true:
(thread->executing () || thread->has_pending_waitstatus ())
... then we ignore the event. The problem is that there are some non-resumed
threads with a pending event, which makes us ignore the event. But these
threads are not resumed, so we end up waiting while nothing executes, hence
waiting for ever.
My first fix was to change the condition to:
(thread->executing ()
|| (thread->resumed () && thread->has_pending_waitstatus ()))
... but then it occured to me that we could simply check for:
(thread->resumed ())
Since "executing" implies "resumed", checking simply for "resumed"
covers threads that are resumed and executing, as well as threads that
are resumed with a pending status, which is what we want.
Change-Id: Ie796290f8ae7f34c026ca3a8fcef7397414f4780
|
|
Add a regression test-case for commit a50bdb99afe "[gdb/tdep, rs6000] Don't
skip system call in skip_prologue":
- set a breakpoint on a local copy of glibc's _exit, and
- verify that it triggers.
The test-case uses an assembly file by default, but also has the possibility
to use a C source file instead.
Tested on ppc64le-linux. Verified that the test-case fails without
aforementioned commit, and passes with the commit. Both with assembly
and C source.
|
|
Add a test-case to excercise the problem scenario reported in PR28527 and
fixed in commit a50bdb99afe "[gdb/tdep, rs6000] Don't skip system call in
skip_prologue":
- set a breakpoint on _exit, and
- verify that it triggers.
Note that this is not a regression test for that commit. Since the actual
code in _exit may vary across os instances, we cannot guarantee that the
problem will always trigger with this test-case.
Rather, this test-case is a version of the original test-case
(gdb.threads/process-dies-while-detaching.exp) that is minimal while still
reproducing the problem reported in PR28527, in that same setting.
The benefit of this test-case is that it exercise real-life code and may
expose similar problems in other settings. Also, it provides a much easier
test-case to investigate in case a similar problem occurs.
Tested on x86_64-linux and ppc64le-linux.
|
|
The purpose of this test is described in the comments in
dprintf-execution-x-script.exp.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28308
The name of this new test was based on that of an existing test,
bp-cmds-execution-x-script.exp. I started off by copying that test,
adding to it, and then rewriting almost all of it. It's different
enough that I decided that listing the copyright year as 2021
was sufficient.
|
|
AddressSanitizer
This test fails for me, showing:
ERROR: tcl error sourcing /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.debuginfod/fetch_src_and_symbols.exp.
ERROR: This GDB was configured as follows:
configure --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-auto-load-dir=$debugdir:$datadir/auto-load
--with-auto-load-safe-path=$debugdir:$datadir/auto-load
... and much more ...
The problem is that TCL's exec throws an error as soon as the exec'ed
process outputs on stderr. When GDB is built with ASan, it prints some
warnings about pre-existing signal handlers:
warning: Found custom handler for signal 7 (Bus error) preinstalled.
warning: Found custom handler for signal 8 (Floating point exception) preinstalled.
warning: Found custom handler for signal 11 (Segmentation fault) preinstalled.
Pass --quiet to GDB to avoid these warnings.
Change-Id: I3751d89b9b1df646da19149d7cb86775e2d3e80f
|
|
When the code to handle DW_LLE_start_end was added (as part of some
DWARF 5 work), it was written to add the base address. However, this
seems incorrect -- the DWARF standard describes this as an address,
not an offset from the base address.
This patch changes a couple of spots in dwarf2/loc.c to fix this
problem. It then changes decode_debug_loc_addresses to return
DEBUG_LOC_OFFSET_PAIR instead, which preserves the previous semantics.
This only showed up on the RISC-V target internally, due to the
combination of DWARF 5 and a newer version of GCC. I've updated a
couple of existing loclists test cases to demonstrate the bug.
|
|
PR 28065 (gdb.threads/access-mem-running-thread-exit.exp intermittent
failure) shows that GDB can hit an unexpected scenario -- it can
happen that the kernel manages to open a /proc/PID/task/LWP/mem file,
but then reading from the file returns 0/EOF, even though the process
hasn't exited or execed.
"0" out of read/write is normally what you get when the address space
of the process the file was open for is gone, because the process
execed or exited. So when GDB gets the 0, it returns memory access
failure. In the bad case in question, the process hasn't execed or
exited, so GDB fails a memory access when the access should have
worked.
GDB has code in place to gracefully handle the case of opening the
/proc/PID/task/LWP/mem just while the LWP is exiting -- most often the
open fails with EACCES or ENOENT. When it happens, GDB just tries
opening the file for a different thread of the process. The testcase
is written such that it stresses GDB's logic of closing/reopening the
/proc/PID/task/LWP/mem file, by constantly spawning short lived
threads.
However, there's a window where the kernel manages to find the thread,
but the thread exits just after and clears its address space pointer.
In this case, the kernel creates a file successfully, but the file
ends up with no address space associated, so a subsequent read/write
returns 0/EOF too, just like if the whole process had execed or
exited. This is the case in question that GDB does not handle.
Oleg Nesterov gave this suggestion as workaround for that race:
gdb can open(/proc/pid/mem) and then read (say) /proc/pid/statm.
If statm reports something non-zero, then open() was "successfull".
I think that might work. However, I didn't try it, because I realized
we have another nasty race that that wouldn't fix.
The other race I realized is that because we close/reopen the
/proc/PID/task/LWP/mem file when GDB switches to a different inferior,
then it can happen that GDB reopens /proc/PID/task/LWP/mem just after
a thread execs, and before GDB has seen the corresponding exec event.
I.e., we can open a /proc/PID/task/LWP/mem file accessing the
post-exec address space thinking we're accessing the pre-exec address
space.
A few months back, Simon, Oleg and I discussed a similar race:
[Bug gdb/26754] Race condition when resuming threads and one does an exec
https://sourceware.org/bugzilla/show_bug.cgi?id=26754
The solution back then was to make the kernel fail any ptrace
operation until the exec event is consumed, with this kernel commit:
commit dbb5afad100a828c97e012c6106566d99f041db6
Author: Oleg Nesterov <oleg@redhat.com>
AuthorDate: Wed May 12 15:33:08 2021 +0200
Commit: Linus Torvalds <torvalds@linux-foundation.org>
CommitDate: Wed May 12 10:45:22 2021 -0700
ptrace: make ptrace() fail if the tracee changed its pid unexpectedly
This however, only applies to ptrace, not to the /proc/pid/mem file
opening case. Also, even if it did apply to the file open case, we
would want to support current kernels until such a fix is more wide
spread anyhow.
So all in all, this commit gives up on the idea of only ever keeping
one /proc/pid/mem file descriptor open. Instead, make GDB open a
/proc/pid/mem per inferior, and keep it open until the inferior exits,
is detached or execs. Make GDB open the file right after the inferior
is created or is attached to or forks, at which point we know the
inferior is stable and stopped and isn't thus going to exec, or have a
thread exit, and so the file open won't fail (unless the whole process
is SIGKILLed from outside GDB, at which point it doesn't matter
whether we open the file).
This way, we avoid both races described above, at the expense of using
more file descriptors (one per inferior).
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28065
Change-Id: Iff943b95126d0f98a7973a07e989e4f020c29419
|
|
Replaces a hard coded line number with a use of gdb_get_line_number.
I suspect that the line number has, over time, come adrift from where
it was supposed to be stopping. When the test was first added, line
770 pointed at the final 'return 0' in function main. Over time, as
things have been added, line 770 now points at some random location in
the middle of main.
So, I've marked the 'return 0' with a comment, and now the test will
always stop there.
I also removed an old comment from 1997 talking about how these tests
will only pass with the HP compiler, followed by an additional comment
from 2000 saying that the tests now pass with GCC.
I get the same results before and after this change.
|
|
The "set index-cache" command is used at the same time as a prefix
command (prefix for "set index-cache directory", for example), and a
boolean setting for turning the index-cache on and off. Even though I
did introduce that, I now don't think it's a good idea to do something
non-standard like this.
First, there's no dedicated CLI command to show whether the index-cache
is enabled, so it has to be custom output in the "show index-cache
handler". Also, it means there's no good way a MI frontend can find out
if the index-cache is enabled. "-gdb-show index-cache" doesn't show it
in the MI output record:
(gdb) interpreter-exec mi "-gdb-show index-cache"
~"\n"
~"The index cache is currently disabled.\n"
^done,showlist={option={name="directory",value="/home/simark/.cache/gdb"}}
Fix this by introducing "set/show index-cache enabled on/off", regular
boolean setting commands. Keep commands "set index-cache on" and "set
index-cache off" as deprecated aliases of "set index-cache enabled",
with respectively the default arguments "on" and "off".
Update tests using "set index-cache on/off" to use the new command.
Update the regexps in gdb.base/maint.exp to figure out whether the
index-cache is enabled or not. Update the doc to mention the new
commands.
Change-Id: I7d5aaaf7fd22bf47bd03e0023ef4fbb4023b37b3
|
|
We see some additional failures when running the testsuite against a GDB
compiled with ASan, compared to a GDB compiled without ASan. Some of
them are caused by the memory leak report shown by the GDB process when
it exits, and the fact that it makes it exit with a non-zero exit code.
I generally try to remember to set ASAN_OPTIONS=detect_leaks=0 in my
environment when running the tests, but I don't always do it. I think
it would be nice if the testsuite did it. I don't see any use to have
leak detection when running the tests. That is, unless we ever have a
test that ensures GDB doesn't leak memory, which isn't going to happen
any time soon.
Here are some tests I found that were affected by this:
gdb.base/batch-exit-status.exp
gdb.base/many-headers.exp
gdb.base/quit.exp
gdb.base/with-mf.exp
gdb.dwarf2/gdb-add-index.exp
gdb.dwarf2/gdb-add-index-symlink.exp
gdb.dwarf2/imported-unit-runto-main.exp
Change-Id: I784c7df8a13979eb96587f735c1d33ba2cc6e0ca
|
|
On powerpc64le-linux, with test-case gdb.arch/powerpc-addpcis.exp I run into
SIGILL:
...
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: get hexadecimal valueof "$r3"
stepi^M
^M
Program terminated with signal SIGILL, Illegal instruction.^M
The program no longer exists.^M
(gdb) PASS: gdb.arch/powerpc-addpcis.exp: set r4
...
because it's a power9 insn, and I'm running on a power8 machine.
Fix this by handling the SIGILL. Likewise in gdb.arch/powerpc-lnia.exp.
Tested on powerpc64le-linux.
|
|
When running test-case gdb.base/step-indirect-call-thunk.exp with target board
unix/-m32/-fPIE/-pie, I run into:
...
(gdb) stepi^M
0x5655552e 22 { /* inc.1 */^M
(gdb) stepi^M
0x56555530 22 { /* inc.1 */^M
(gdb) stepi^M
0x565555f7 in __x86.get_pc_thunk.ax ()^M
(gdb) FAIL: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
...
In contrast, with unix/-m32 we have instead:
...
(gdb) stepi^M
0x08048407 22 { /* inc.1 */^M
(gdb) stepi^M
23 return x + 1; /* inc.2 */^M
(gdb) stepi^M
0x0804840c 23 return x + 1; /* inc.2 */^M
(gdb) stepi^M
24 } /* inc.3 */^M
(gdb) stepi^M
0x08048410 24 } /* inc.3 */^M
(gdb) stepi^M
0x0804848f in __x86_return_thunk ()^M
(gdb) PASS: gdb.base/step-indirect-call-thunk.exp: stepi into return thunk
...
The test-case doesn't expect to run into __x86.get_pc_thunk.ax, which is a
PIC helper function for x86_64-linux.
Fix this by insn-stepping through it.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
On my branch that replaces the DWARF psymtab reader,
dw2-stack-boundary.exp started failing. However, when I look at the
output in gdb.log, it is correct:
file /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary
Reading symbols from /home/tromey/gdb/build/gdb/testsuite/outputs/gdb.dwarf2/dw2-stack-boundary/dw2-stack-boundary...
During symbol reading: location description stack overflow
During symbol reading: location description stack underflow
What happens to cause the failure is that the two branches in
gdb_test_multiple appear in this order:
-re "\r\nDuring symbol reading: location description stack underflow" {
[...]
-re "\r\nDuring symbol reading: location description stack overflow" {
The first one will match the above, without causing the second one to
ever match -- leading to a spurious failure.
Anchoring the regexps seems to fix the problem, and works for the
current gdb as well.
|
|
On a machine with gcc 11, I get:
FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_v" (second tab) (timeout)
FAIL: gdb.gdb/unittest.exp: test_completion: tab complete "maintenance selftest string_vie" (timeout)
That's because when compiling with C++ >= 17, we use the standard
version of string_view, and don't have a selftest for it. So the list
of selftests shown by the tab completion when completing "string_v"
differs.
Change the test to use the copy_* tests instead.
Change-Id: I85f6aa44ee5fc9652b9bd4451e0506b89773526b
|
|
Add 'set debuginfod' command. Accepts 'on', 'off' or 'ask' as an
argument. 'on' enables debuginfod for the current session. 'off'
disables debuginfod for the current session. 'ask' will prompt
the user to either enable or disable debuginfod when the next query
is about to be performed:
This GDB supports auto-downloading debuginfo from the following URLs:
<URL1> <URL2> ...
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod on' to .gdbinit.
For interactive sessions, 'ask' is the default. For non-interactive
sessions, 'off' is the default.
Add 'show debuginfod status' command. Displays whether debuginfod
is set to 'on', 'off' or 'ask'.
Add 'set/show debuginfod urls' commands. Accepts a string of
space-separated debuginfod server URLs to be queried. The default
value is copied from the DEBUGINFOD_URLS environment variable.
Finally add 'set/show debuginfod verbose' commands to control whether
debuginfod-related output is displayed. Verbose output is enabled
by default.
(gdb) run
Starting program: /bin/sleep 5
Download failed: No route to host. Continuing without debug info for /lib64/libc.so.6.
If GDB is not built with debuginfod then these commands will just display
Support for debuginfod is not compiled into GDB.
|
|
This adds a new Python function, gdb.Architecture.integer_type, which
can be used to look up an integer type of a given size and
signed-ness. This is useful to avoid dependency on debuginfo when a
particular integer type would be useful.
v2 moves this to be a method on gdb.Architecture and addresses other
review comments.
|
|
A build with --disable-unit-tests currently run into:
...
ld: maint.o: in function \
`maintenance_selftest_completer(cmd_list_element*, completion_tracker&,
char const*, char const*)':
src/gdb/maint.c:1183: undefined reference to \
`selftests::for_each_selftest(
gdb::function_view<
void (std::__cxx11::basic_string<char,std::char_traits<char>,
std::allocator<char> > const&)>)'
...
Fix this by guarding the call to selftests::for_each_selftest in
maintenance_selftest_completer with GDB_SELF_TEST, such that the "-verbose"
completion still works.
Rebuild on x86_64-linux and ran gdb.gdb/unittest.exp.
|
|
After the previous commit, it is easy to add completion for selftest
names. Again, this is not particularly high value, but I rarely touched
completion, so it served as a simple example to get some practice.
Change the for_each_selftest_ftype parameter to gdb::function_view, so
that we can pass a lambda that captures things.
Change-Id: I87cac299ddca9ca7eb0ffab78342e850a98d954c
|
|
I noticed some files in the test-suite have GPLv2 notices.
Update these to GPLv3.
|
|
I came across this when running test-case gdb.server/server-kill-python.exp
with a gdb configured without python:
...
builtin_spawn gdb -nw -nx -data-directory data-directory -iex set height 0 \
-iex set width 0 -quiet -iex set height 0 -iex set width 0 \
-ex source outputs/gdb.server/server-kill-python/file1.py^M
FAIL: gdb.server/server-kill-python.exp: ensure inferior is running
Executing on target: kill -9 28535 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 28535^M
file1.py:1: Error in sourced command file:^M
Undefined command: "import". Try "help".^M
...
Fix this by testing for python support in the test-case.
Tested on aarch64-linux (with python support disabled) and x86_64-linux (with
python support enabled).
|
|
On openSUSE Leap 15.2 aarch64 I ran into:
...
clang-debug-names-debug.S:72: \
Error: junk at end of line, first unrecognized character is `#'
...
due to:
...
71 .Ldebug_names_start:
72 .short 5 # Header: version
...
Fix this by using the /* ... */ comment style instead:
...
$ sed -i 's% #\([^"]*\)%/*\1 */%' clang-debug-names.exp.tcl
...
Tested on aarch64-linux and x86_64-linux.
|
|
Consider a fortran routine where a string variable s is modified:
...
subroutine f(s)
character*(*) s
print *, s
s(1:3) = 'oof'
print *, s
end subroutine f
...
When compiling with optimization level -O1 and printing the type of
variable s we get:
...
$ gdb -q -batch outputs/gdb.opt/fortran-string/fortran-string \
-ex "b f" \
-ex run \
-ex "ptype s"
Breakpoint 1 at 0x4006f7: file fortran-string.f90, line 21.
Breakpoint 1, f (s=..., _s=_s@entry=3) at fortran-string.f90:21
21 subroutine f(s)
type = character*1
...
while with -O0 we have instead:
...
type = character (3)
...
The problem is that the type of s is:
...
<1><2d6>: Abbrev Number: 21 (DW_TAG_string_type)
<2d7> DW_AT_string_length: 0xbf (location list)
<2db> DW_AT_byte_size : 4
...
where the DW_AT_string_length is a location list, a case that is not handled
by attr_to_dynamic_prop.
Fix this by handling attr->form_is_section_offset () in attr_to_dynamic_prop.
Tested on x86_64-linux.
The test-case is based on gdb.opt/fortran-string.exp from
https://src.fedoraproject.org/rpms/gdb/raw/f32/f/gdb-archer-vla-tests.patch .
I've updated the copyrights to stretch to 2021.
[ I've tried to create a dwarf assembly test-case for this, but didn't
manage. ]
Co-Authored-By: Jan Kratochvil <jan.kratochvil@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26910
|
|
GDB test fails while running the test case gdb.cp/koenig.exp using
clang compiler:
[...]
p foo (p_union)
No symbol "p_union" in current context.
(gdb) FAIL: gdb.cp/koenig.exp: p foo (p_union)
[...]
In the testcase, "p_union" is an unused/uninitialized variable of
anonymous union type. Clang does not emit symbol for unused anonymous
union/struct variables at any optimization level. Since the compiler
itself is not emitting the symbol for "p_union", debug info is also
not emitted when built with debug option. If the anonymous union is
initialized (or used), then clang emits the symbol "p_union" which
enables emitting debug info for "p_union".
[...]
p foo (p_union)
Cannot resolve function foo to any overloaded instance
(gdb) PASS: gdb.cp/koenig.exp: p foo (p_union)
[...]
|
|
On OBS I ran into this failure with test-case
gdb.debuginfod/fetch_src_and_symbols.exp:
...
Failed to listen for connections: Address already in use^M
[Thu Oct 21 11:48:49 2021] (559/559): started http server on IPv6 port=8000^M
...
FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: find port timeout
...
The test-case is trying to start debuginfod on a port to see if it's
available, and it handles either this message:
"started http server on IPv4 IPv6 port=$port"
meaning success, or:
"failed to bind to port"
meaning failure, in which case the debuginfod instance is killed, and we try
the next port.
The test-case only uses the v4 address 127.0.0.1, so fix this by:
- accepting "started http server on IPv4 port=$port"
- rejecting "started http server on IPv6 port=$port"
Tested on x86_64-linux.
|
|
With test-case gdb.mi/mi-var-cp.exp I run into this duplicate:
...
PASS: gdb.mi/mi-var-cp.exp: run to mi-var-cp.cc:104 (set breakpoint)
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
PASS: gdb.mi/mi-var-cp.exp: create varobj for s
DUPLICATE: gdb.mi/mi-var-cp.exp: create varobj for s
...
This is due to a duplicate test name here:
...
$ cat -n gdb/testsuite/gdb.mi/mi-var-cp.cc
...
100 int reference_to_struct ()
101 {
102 /*: BEGIN: reference_to_struct :*/
103 S s = {7, 8};
104 S& r = s;
105 /*:
106 mi_create_varobj S s "create varobj for s"
107 mi_create_varobj R r "create varobj for s"
...
Fix this by using "create varobj for r" instead.
Tested on x86_64-linux.
|
|
On openSUSE Tumbleweed with glibc-debuginfo installed I get:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread (arg=<optimized out>) \
at pthread_create.c:435^M
#3 0x00007ffff7ddb640 in clone3 () \
at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81^M
(gdb) PASS: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
while without debuginfo installed I get instead:
...
(gdb) PASS: gdb.threads/linux-dp.exp: continue to breakpoint: thread 5's print
where^M
#0 print_philosopher (n=3, left=33 '!', right=33 '!') at linux-dp.c:105^M
#1 0x0000000000401628 in philosopher (data=0x40537c) at linux-dp.c:148^M
#2 0x00007ffff7d56b37 in start_thread () from /lib64/libc.so.6^M
#3 0x00007ffff7ddb640 in clone3 () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/linux-dp.exp: first thread-specific breakpoint hit
...
The problem is that the regexp used:
...
"\(from .*libpthread\|at pthread_create\|in pthread_create\)"
...
expects the 'from' part to match libpthread, but in glibc 2.34 libpthread has
been merged into libc.
Fix this by updating the regexp.
Tested on x86_64-linux.
|
|
Since commit e36788d1354 "[gdb/testsuite] Fix handling of nr_args < 3 in
mi_gdb_test" we run into:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: mi runto main
Expecting: ^(-break-insert -f pendfunc1[^M
]+)?((&.*)*.*~"Breakpoint 2 at.*\\n".*=breakpoint-created,\
bkpt=\{number="2",type="breakpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-insert -f pendfunc1^M
^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",\
addr="0x00007ffff7bd559e",func="pendfunc1",\
file="gdb/testsuite/gdb.mi/pendshr1.c",\
fullname="gdb/testsuite/gdb.mi/pendshr1.c",line="21",thread-groups=["i1"],\
times="0",original-location="pendfunc1"}^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1 (unexpected output)
...
The regexp expects a breakpoint-created event, but that's actually suppressed
by the command:
...
DEF_MI_CMD_MI_1 ("break-insert", mi_cmd_break_insert,
&mi_suppress_notification.breakpoint),
...
Fix this by updating the regexp.
Likewise for the following:
...
PASS: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-insert -f pendfunc1
Expecting: ^(-break-enable count 1 2[^M
]+)?(=breakpoint-modified,\
bkpt=\{number="2",type="breakpoint",disp="dis",enabled="y".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-break-enable count 1 2^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_auto_disable: \
-break-enable count 1 2 (unexpected out\
put)
...
Tested on x86_64-linux.
|
|
Add a new function to the Python API, gdb.architecture_names(). This
function returns a list containing all of the supported architecture
names within the current build of GDB.
The values returned in this list are all of the possible values that
can be returned from gdb.Architecture.name().
|
|
Update the expected pattern for two of the tests.
Matching pattern \" doesn't work. Use .* to match the \* pattern.
|
|
In commit 81e6b8eb208 "Make tui-winsource not use breakpoint_chain", a loop
body was transformed into a lambda function body:
...
- for (bp = breakpoint_chain;
- bp != NULL;
- bp = bp->next)
+ iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
...
and consequently:
- a continue was replaced by a return, and
- a final return was added.
Then in commit 240edef62f0 "gdb: remove iterate_over_breakpoints function", we
transformed back to a loop body:
...
- iterate_over_breakpoints ([&] (breakpoint *bp) -> bool
+ for (breakpoint *bp : all_breakpoints ())
...
but without reverting the changes that introduced the two returns.
Consequently, breakpoints no longer show up in the tui source window.
Fix this by reverting the changes that introduced the two returns.
Build on x86_64-linux, tested with all .exp test-cases that contain
tuiterm_env.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28483
|
|
The test expect the runto_main to stop at the first line of the function.
Depending on the optimization level, gdb may stop in the prolog or after
the prolog at the first line. To ensure the test stops at the first line
of main, have it explicitly stop at a break point on the first line of the
function.
On PowerPC, the test passes when compiled with no optimization but fails
with all levels of optimization due to gdb stopping in the prolog.
|
|
The "add accessors for field (and call site) location" patch caused a
gdb crash when running the internal AdaCore testsuite. This turned
out to be a latent bug in ada-lang.c.
The immediate cause of the bug is that find_struct_field
unconditionally uses TYPE_FIELD_BITPOS. This causes an assert for a
dynamic type.
This patch fixes the problem by doing two things. First, it changes
find_struct_field to use a dummy value for the field offset in the
situation where the offset is not actually needed by the caller. This
works because the offset isn't used in any other way -- only as a
result.
Second, this patch assures that calls to find_struct_field use a
resolved type when the offset is needed. For
value_tag_from_contents_and_address, this is done by resolving the
type explicitly. In ada_value_struct_elt, this is done by passing
nullptr for the out parameters when they are not needed (the second
call in this function already uses a resolved type).
Note that, while we believe the parent field probably can't occur at a
variable offset, the patch still updates this code path, just in case.
I've updated an existing test case to reproduce the crash.
I'm checking this in.
|
|
The test-case gdb.gdb/python-interrupts.exp:
- runs to captured_command_loop
- sets a breakpoint at set_active_ext_lang
- calls a python command
- verifies the command triggers the breakpoint
- sends a signal and verifies the result
The test-case is fragile, because (f.i. with -flto) it cannot be guaranteed
that captured_command_loop and set_active_ext_lang are available for setting
breakpoints.
Reimplement the test-case as unittest, using:
- execute_command_to_string to capture the output
- try/catch to catch the "Error while executing Python code" exception
- a new hook selftests::hook_set_active_ext_lang to raise the signal
Tested on x86_64-linux.
|
|
A customer-reported problem led us to a bug in dynamic type
resolution. resolve_dynamic_struct will recursively call
resolve_dynamic_type_internal, passing it the sub-object for the
particular field being resolved. While it offsets the address here,
it does not also offset the "valaddr" -- the array of bytes describing
the memory.
This patch fixes the bug, by offsetting both. A test case is included
that can be used to reproduce the bug.
|
|
Add .debug_loc support in the dwarf assembler, and use it in new test-case
gdb.dwarf2/loc-sec-offset.exp (which is based on
gdb.dwarf2/loclists-sec-offset.exp).
Tested on x86_64-linux.
|
|
When printing a variable x in a subroutine foo:
...
subroutine foo (x)
integer(4) :: x (*)
x(3) = 1
end subroutine foo
...
where x is an array with unknown bounds, we get:
...
$ gdb -q -batch outputs/gdb.fortran/array-no-bounds/array-no-bounds \
-ex "break foo" \
-ex run \
-ex "print x"
Breakpoint 1 at 0x4005cf: file array-no-bounds.f90, line 18.
Breakpoint 1, foo (x=...) at array-no-bounds.f90:18
18 x(3) = 1
$1 = <error reading variable>
...
Improve the error message by printing the details of the error, such that we
have instead:
...
$1 = <error reading variable: failed to get range bounds>
...
This is a change in gdb/valprint.c, and grepping through the sources reveals
that this is a common pattern.
Tested on x86_64-linux.
|
|
When running test-case gdb.fortran/call-no-debug.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.fortran/call-no-debug.exp: print string_func_ (&'abcdefg', 3)
call (integer) string_func_ (&'abcdefg', 3)^M
$2 = 0^M
(gdb) FAIL: gdb.fortran/call-no-debug.exp: call (integer) string_func_ (&'abcdefg', 3)
...
The problem is that gdb_test is used to match inferior output.
Fix this by using gdb_test_stdio.
Tested on x86_64-linux.
|
|
When running with target board native-gdbserver, we run into a number of FAILs
due to use of the start command (and similar), which is not supported when
use_gdb_stub == 1.
Fix this by:
- requiring use_gdb_stub == 0 for the entire test-case, or
- guarding some tests in the test-case with use_gdb_stub == 0.
Tested on x86_64-linux.
|
|
When running test-case gdb.python/python.exp, we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via interactive input
...
The two tests are instances of the same test, with different values for
starti command argument from_tty, so it's strange that the test names are so
different.
This is due to using a gdb_test nested in a gdb_test_multiple, with the inner
one using a different test name than the outer one. [ That could still make
sense if both produced passes, but that's not the case here. ]
Fix this by using $gdb_test_name, such that we have:
...
PASS: gdb.python/python.exp: starti via gdb.execute, not from tty
PASS: gdb.python/python.exp: starti via gdb.execute, from tty
...
Also make this more readable by using variables.
Tested on x86_64-linux.
|
|
When running test-case gdb.base/batch-exit-status.exp with target board
native-gdbserver, I run into (added missing double quotes for clarity):
...
builtin_spawn $build/gdb/testsuite/../../gdb/gdb -nw -nx \
-data-directory $build/gdb/testsuite/../data-directory \
-iex "set height 0" -iex "set width 0" \
-ex "set auto-connect-native-target off" \
-iex "set sysroot" -batch ""^M
: No such file or directory.^M
PASS: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 2] == 0
FAIL: gdb.base/batch-exit-status.exp: 1x: \
No such file or directory: [lindex $result 3] == $expect_status
...
As in commit a02a90c114c "[gdb/testsuite] Set sysroot earlier in
local-board.exp", the problem is the use of -ex for
"set auto-connect-native-target off", which makes that the last command to
be executed, and consequently determines the return status.
Fix this by using -iex instead.
Tested on x86_64-linux.
|
|
When running test-case gdb.arch/i386-mpx.exp with target board
native-gdbserver, I run into:
...
(gdb) PASS: gdb.arch/i386-mpx.exp: verify size for bnd0
Remote debugging from host ::1, port 42328^M
quit^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) monitor exit^M
Please answer y or n.^M
A debugging session is active.^M
^M
Inferior 1 [process 19679] will be killed.^M
^M
Quit anyway? (y or n) WARNING: Timed out waiting for EOF in server after monitor exit
...
The problem is that the test-case sends a quit at the end (without verifying
the result of this in any way):
...
send_gdb "quit\n"
...
Fix this by removing the quit.
Tested on x86_64-linux.
|
|
When running test-case gdb.mi/mi-var-child-f.exp on openSUSE Tumbleweed
(with glibc 2.34) I run into:
...
(gdb) ^M
PASS: gdb.mi/mi-var-child-f.exp: mi runto prog_array
Expecting: ^(-var-create array \* array[^M
]+)?(\^done,name="array",numchild="[0-9]+",value=".*",type=.*,has_more="0"[^M
]+[(]gdb[)] ^M
[ ]*)
-var-create array * array^M
&"Attempt to use a type name as an expression.\n"^M
^error,msg="-var-create: unable to create variable object"^M
(gdb) ^M
FAIL: gdb.mi/mi-var-child-f.exp: create local variable array (unexpected output)
...
The problem is that the name array is used both:
- as the name for a local variable
- as the name of a type in glibc, in file malloc/dynarray-skeleton.c, as included
by nss/nss_files/files-hosts.c.
Fix this by ignoring the shared lib symbols.
Likewise in a couple of other fortran tests.
Tested on x86_64-linux.
|
|
A mistake slipped in in commit a5ea23036d8 "[gdb/testsuite] Use function_range
in gdb.dwarf2/dw2-ref-missing-frame.exp".
Before the commit the main file was compiled with debug info, and the two
others not:
...
if {[prepare_for_testing_full "failed to prepare" \
[list $testfile {} $srcfile {} $srcfuncfile {} \
$srcmainfile debug]]} {
...
After the commit, all were compiled with debug info, and consequently, there
are two versions of debug info for $srcfuncfile. This shows up as a FAIL when
running the test-case with target boards readnow and cc-with-debug-names.
Fix this by using prepare_for_testing_full, as before.
Tested on x86_64-linux.
Fixes: a5ea23036d8 ("[gdb/testsuite] Use function_range in
gdb.dwarf2/dw2-ref-missing-frame.exp")
|
|
Replace:
...
if { [ensure_gdb_index $binfile] == -1 } {
return -1
}
...
with:
...
require {ensure_gdb_index $binfile} != -1
...
and consequently, add a missing UNTESTED message.
Tested on x86_64-linux, both with native and target board readnow.
|
|
When running test-case gdb.base/with-mf.exp with target board readnow, I run
into:
...
FAIL: gdb.base/with-mf.exp: check if index present
...
This is since commit 6010fb0c49e "[gdb/testsuite] Fix full buffer in
gdb.rust/dwindex.exp".
Before that commit, the proc ensure_gdb_index would treat the line:
...
.gdb_index: faked for "readnow"^M
...
as proof that an index is already present (which is incorrect).
Now, instead it generates aforementioned FAIL and continues to generate an
index.
Fix this by explicitly handling the readnow case in proc ensure_gdb_index,
such that we bail out instead.
Tested on x86_64-linux.
|
|
The test-case gdb.dwarf2/gdb-add-index-symlink.exp interpretes a failure to
add an index as a failure to add an index for a symlink:
...
if { [ensure_gdb_index $symlink] == -1 } {
fail "Unable to call gdb-add-index with a symlink to a symfile"
return -1
}
...
However, it's possible that the gdb-add-index also fails with a regular
file. Add a check for that situation.
Tested on x86_64-linux.
|
|
Add a new proc require in lib/gdb.exp, and use it to shorten:
...
if { [gdb_skip_xml_test] } {
# Valgrind gdbserver requires gdb with xml support.
untested "missing xml support"
return 0
}
...
into:
...
require gdb_skip_xml_test 0
...
Tested on x86_64-linux, both with and without a trigger patch that forces
gdb_skip_xml_test to return 1.
|
