| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
An upstream bug report points out this bug: if the user switches from
one Ada executable to another without "kill"ing the inferior, then the
"start" command will fail.
What happens here is that the Ada "main" name is found in a constant
string in the executable. But, if the inferior is running, then the
process_stratum target reads from the inferior memory.
This patch fixes the problem by changing the main name code to set
trust-readonly-sections, causing the target stack to read from the
executable instead.
I looked briefly at changing GNAT to emit DW_AT_main_subprogram
instead, but this looks to be pretty involved.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25811
|
|
A user noticed that gdb would crash when showing a backtrace.
Investigation showed this to be a crash in the DWARF reader when
handling a "pragma export" symbol. The bug here is that earlier code
decides to eliminate the symbol, but the export code tries to add it
anyway -- but to a NULL list.
|
|
When running test-case gdb.base/add-symbol-file-attach.exp with target board
unix/-m32, we run into:
...
(gdb) attach 3955^M
Attaching to process 3955^M
Load new symbol table from "add-symbol-file-attach"? (y or n) y^M
Reading symbols from add-symbol-file-attach/add-symbol-file-attach...^M
Reading symbols from /lib/libm.so.6...^M
Reading symbols from /usr/lib/debug/lib/libm-2.31.so-i386.debug...^M
Reading symbols from /lib/libc.so.6...^M
Reading symbols from /usr/lib/debug/lib/libc-2.31.so-i386.debug...^M
Reading symbols from /lib/ld-linux.so.2...^M
Reading symbols from /usr/lib/debug/lib/ld-2.31.so-i386.debug...^M
0xf7f53549 in __kernel_vsyscall ()^M
(gdb) FAIL: gdb.base/add-symbol-file-attach.exp: attach
...
The test fails because this regexp is used:
...
-re ".*in \[_A-Za-z0-9\]*pause.*$gdb_prompt $" {
...
The regexp attempts to detect that the exec is somewhere in pause ():
...
int
main (int argc, char **argv)
{
pause ();
return 0;
}
...
but when the exec is blocked in pause, the backtrace is:
...
(gdb) bt
#0 0xf7fd2549 in __kernel_vsyscall ()
#1 0xf7d84966 in __libc_pause () at ../sysdeps/unix/sysv/linux/pause.c:29
#2 0x0804844c in main (argc=1, argv=0xffffce84)
at /data/vries/gdb/src/gdb/testsuite/gdb.base/add-symbol-file-attach.c:26
...
We could simply extend the regexp to also match __kernel_vsyscall, but the
more fundamental problem is that the test is racy.
The attach can happen before the exec is blocked in pause (), somewhere in the
dynamic linker resolving the call to pause, in main or even earlier.
Note that for the test-case to be effective, the exec is not required to be in
pause (). I added a "while (1);" loop at the start of main, reverted the
patch fixing the corresponding PR and reproduced the problem it's supposed to
detect.
Fix this by simply matching the "Reading symbols from" line, similar to what
an earlier test is doing.
While we're at it, rewrite the earlier test to also use the -wrap idiom.
Tested on x86_64-linux.
|
|
This commit adds a new test case for bug 27831. See the contents
of the .exp file for a description of what it's about.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27831
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.dwarf2/nullptr_t.exp with target board
cc-with-dwz-m, I run into:
...
FAIL: gdb.dwarf2/nullptr_t.exp: decltype(nullptr) symbol
...
The problem is that were looking for "typedef void decltype\\(nullptr\\)"
using "maint print symbols -source $srcfile", but dwz has moved the typedef to
a PU, so it's shown by "maint print symbols -source <unknown>" instead.
Fix this by dropping the "-source $srcfile" bit.
Tested on x86_64-linux, with make-check-all.sh.
|
|
gdb.reverse/step-precsave.exp
When running this test on a processor that supports AVX512 (AMD EPYC
9634) on Debian 12 bookwork (system compiler is gcc 12.2.0), I see:
continue^M
Continuing.^M
Process record does not support instruction bound.^M
Process record does not support instruction 0x62 at address 0x7ffff7f49b40.^M
Process record: failed to record execution log.^M
^M
Program stopped.^M
0x00007ffff7f49b40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6^M
(gdb) FAIL: gdb.reverse/step-precsave.exp: run to end of main
The instruction at this address is:
0x00007ffff7f49b40: 62 e2 7d 48 7a c6 vpbroadcastb %esi,%zmm16
This seems like an AVX512 instruction (given the use of zmm16). Match
this byte value in order to produce a KFAIL.
Change-Id: I1d20357fa538ba60b9c537160acf511a37d751ee
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30807
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.arch/i386-avx512.exp with gcc 4.8.4, I run into:
...
Running gdb.arch/i386-avx512.exp ...
gdb compile failed, gcc: error: unrecognized command line option '-mavx512f'
...
Fix this by requiring have_compile_flag -mavx512f.
Tested on x86_64-linux.
|
|
When running test-case gdb.linespec/cpls-abi-tag.exp with gcc 4.8.4, we run
into:
...
cpls-abi-tag.cc:71:26: error: ‘abi_tag’ attribute applied to non-function ‘s’
ABI3 test_abi_tag_struct s;
^
...
The test-case is supported starting gcc 5.
Fix this by requiring gcc >= 5, if a gcc compiler is used.
Tested on x86_64-linux.
|
|
When running test-case gdb.mi/print-simple-values.exp with gcc 4.8.4, I run
into a compilation failure due to the test-case requiring c++11 and the
compiler defaulting to less than that.
Fix this by compiling with -std=c++11.
Likewise in a few other test-cases.
Tested on x86_64-linux.
|
|
In test-case gdb.tui/pr30056.exp we check for:
...
require {have_host_locale C.UTF-8}
...
The "C.UTF-8" is normalized by have_host_locale to "c.utf8", before trying to
find it in the list returned by host_locales.
On my development platform, "locale -a" lists C.utf8, which is normalized to
"c.utf8" by host_locales, so there's a match and have_host_locale returns true.
On another platform however, "locale -a" lists C.UTF-8, which is normalized to
"c.utf-8" by host_locales, so there's no match and have_host_locale returns false.
Fix this by also dropping the dash in host_locales.
Tested on x86_64-linux.
|
|
When running test-case gdb.reverse/getrandom.exp on a system with eglibc 2.19,
we run into:
...
gdb compile failed, gdb.reverse/getrandom.c:18:24: fatal error: \
sys/random.h: No such file or directory
#include <sys/random.h>
^
compilation terminated.
=== gdb Summary ===
# of untested testcases 1
...
and:
...
UNTESTED: gdb.reverse/getrandom.exp: failed to prepare
...
Fix this by testing for the presence of the header, such that we have instead:
...
UNSUPPORTED: gdb.reverse/getrandom.exp: require failed: \
have_system_header sys/random.h
...
Tested on x86_64-linux and i686-linux.
|
|
In test-case gdb.cp/nsusing.exp I came across these xfails without PRMS
mentioned:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement
XFAIL: gdb.cp/nsusing.exp: print x, only using M
...
Add the missing PRMS, such that we have:
...
XFAIL: gdb.cp/nsusing.exp: print x, before using statement (PRMS gcc/108716)
XFAIL: gdb.cp/nsusing.exp: print x, only using M (PRMS gcc/108716)
...
and limit the xfail to unfixed versions.
The PR is fixed starting gcc 13, but it has been backported to release
branches stretching back to gcc 10. For simplicity we just stick to testing
for the major version and ignore the backported fixes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Building gdb with gcc 7.5.0 and -flto -O2 -flto-partition=one generates a
self-referencing DIE:
...
<2><91dace>: Abbrev Number: 405 (DW_TAG_label)
<91dad0> DW_AT_abstract_origin: <0x91dace>
...
When encountering the self-reference DIE in inherit_abstract_dies we loop
following the abstract origin, effectively hanging gdb.
Fix this by handling self-referencing DIEs in the loop in
inherit_abstract_dies.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30799
https://sourceware.org/bugzilla/show_bug.cgi?id=30799
|
|
When running test-case gdb.cp/subtypes.exp with gcc 4.8.4, we run into:
...
FAIL: gdb.cp/subtypes.exp: ptype main::Foo
FAIL: gdb.cp/subtypes.exp: ptype main::Bar
FAIL: gdb.cp/subtypes.exp: ptype main::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<int>::Baz
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Foo
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Bar
FAIL: gdb.cp/subtypes.exp: ptype foobar<char>::Baz
...
The problem is gcc PR debug/55541, which generates a superfluous
DW_TAG_lexical_block.
Add a corresponding xfail.
Tested on x86_64-linux.
|
|
Make test-case gdb.cp/subtypes.exp less repetitive by using foreach.
Tested on x86_64-linux.
|
|
When running test-cases gdb.cp/*.exp with gcc 4.8.4, I run into compilation
failures due to the test-cases requiring c++11 and the compiler defaulting
to less than that.
Fix this by compiling with -std=c++11.
This exposes two FAILs in gdb/testsuite/gdb.cp/empty-enum.exp due to
gcc PR debug/16063, so xfail those.
Also require have_compile_flag -std=c++17 in gdb.cp/constexpr-field.exp to
prevent compilation failure.
Tested on x86_64-linux.
|
|
The author of 'mold' pointed out that with a certain shared library,
gdb would fail to find the shared library's name in 'bt'.
The function in question appeared at the end of the .so's .text
segment and ended with a call to 'abort'.
This turned out to be a classic case of calling get_frame_pc when
get_frame_address_in_block is needed -- the former will be off-by-one
for purposes of finding the enclosing function or shared library.
The included test fails without the patch on my system. However, I
imagine it can't be assumed to reliably fail. Nevertheless it seemed
worth doing.
Regression tested on x86-64 Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29074
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
|
|
This commits tackles 2 problems in the test
gdb.reverse/insn-reverse.exp. They are, broadly: flawed logic when an
unexpected error occurs, and badly formed asm expressions.
For the first, what happens is that if the inferior stops progressing
for some reason, the test will emit an UNSUPPORTED and continue testing
by reversing from the current location and checking all registers for
every instruction. However, due to how the outputs are indexed in the
test, this early exit will cause most of the subsequent tests to be
de-synced and will emit many unrelated failures.
This commit changes the UNSUPPORTED for a FAIL, since the test has in
fact failed to record the execution of the whole function, and
decrements the recorded instruction count by one so that the indexes are
in sync once more.
At the time of committing, this reduces the amount of failures when
testing with clang-15 from around 150 to 2, and correctly identifies
where the issue lies.
The second problem is in how the asm statements in the *-x86.c file
are written. As an example, let's examine the following line:
__asm__ volatile ("rdrand %%ebp;" : "=r" (number));
This statement says that number is being used as the output variable,
but is not indicating which registers were clobbered so that the
compiler is able to properly output. GCC decides to just not save
anything, whereas clang assumes that the output is in %rax, and writes
it to the variable. This hid the problem that any compiler is not good
at dealing with asm statements that change the rbp register. It can be
seen more explicitly by informing gcc that rbp has been clobbered like
so:
__asm__ volatile ("rdrand %%ebp;" : "=r" (number) : : "%ebp");
This statement gets compiled into the following assembly:
rdrandl %ebp
movl %eax, -4(%rbp)
Which is clearly using the incorrect rbp to find the memory location of
the variable. Since the test only exercises GDB's ability to record the
register changes, this commit removes the output to memory.
Finally, correctly informing the compiler of clobbered registers
makes gcc throw an error that the rsp is no longer usable at the end of
the function. To avoid that, this commit compresses the 3 asm statements
that would save, change and reset registers into a single asm statement.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When testing using reverse-stepi to fully step through a function, the
code checks for an infinite loop by seeing if we land on the line that
contains the return statement multiple times. This assumption only works
if there is only one instruction associated with that line, which is how
GCC handles line information, but other compilers may handle it differently.
Clang-15, for instance, associates 6. Because of this, the inferior used
to get seriously out of sync with the test expectations, and result in 13
spurious failures. The same issue occurs with gdb.reverse/step-precsave.exp.
This commit changes the test so that we check for PC instead of line
number. The test still only happens when the same line is detected, to
simplify the resulting log. With this change, no new failures are
emitted when using clang.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The tests gdb.reverse/solib-precsave.exp and solib-reverse.exp have the
assumption that line tables will have an entry for the closing } in a
function. Not all compiles do this, one example being clang. To fix
this, this commit changes the function in shr2.c to have multiple lines,
and the test to accept either line as a correct step location.
To properly re-sync the inferiors, the function repeat_cmd_until had to
be slightly changed to work with empty "current locations", so that we
are able to step through multiple lines.
This also changes the annotations used to determine the breakpoint
locations in solib-reverse.c, adding a simple variable assignment right
before the return statement. This way GDB will not set a breakpoint in
the closing } line.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Clang does not add line information for lines that only contain a
closing } in functions. Many tests in the gdb.reverse folder set a
breakpoint in that line, but don't seem to use information available
after the return statement is executed, so this commit moves the
breakpoint to the previous line, where the return statement is.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This recent commit:
commit b1c0ab20809a502b2d2224fecb0dca3ada2e9b22
Date: Wed Jul 12 21:56:50 2023 +0100
gdb: avoid double stop after failed breakpoint condition check
Addressed a problem where two MI stopped events would be reported if a
breakpoint condition failed due to a signal, this commit was a
replacement for this commit:
commit 2e411b8c68eb2b035b31d5b00d940d4be1a0928b
Date: Fri Oct 14 14:53:15 2022 +0100
gdb: don't always print breakpoint location after failed condition check
which solved the two stop problem, but only for the CLI. Before both
of these commits, if a b/p condition failed due to a signal then the
user would see two stops reported, the first at the location where the
signal occurred, and the second at the location of the breakpoint.
By default GDB remains at the location where the signal occurred, so
the second reported stop can be confusing, this is the problem that
commit 2e411b8c68eb tried to solve (for the CLI) and b1c0ab20809a
extended also address the issue for MI too.
However, while working on another patch I realised that there was a
problem with GDB after the above commits. Neither of the above
commits considered 'set unwindonsignal on'. With this setting on,
when an inferior function call fails with a signal GDB will unwind the
stack back to the location where the inferior function call started.
In the b/p case we're looking at, the stop should be reported at the
location of the breakpoint, not at the location where the signal
occurred, and this isn't what happens.
This commit fixes this by ensuring that when unwindonsignal is 'on',
GDB reports a single stop event at the location of the breakpoint,
this fixes things for both CLI and MI.
The function call_thread_fsm::should_notify_stop is called when the
inferior function call completes and GDB is figuring out if the user
should be notified about this stop event by calling normal_stop from
fetch_inferior_event in infrun.c. If normal_stop is called, then this
notification will be for the location where the inferior call stopped,
which will be the location at which the signal occurred.
Prior to this commit, the only time that normal_stop was not called,
was if the inferior function call completed successfully, this was
controlled by ::should_notify_stop, which only turns false when the
inferior function call has completed successfully.
In this commit I have extended the logic in ::should_notify_stop. Now
there are three cases in which ::should_notify_stop will return false,
and we will not announce the first stop (by calling normal_stop).
These three reasons are:
1. If the inferior function call completes successfully, this is
unchanged behaviour,
2. If the inferior function call stopped due to a signal and 'set
unwindonsignal on' is in effect, and
3. If the inferior function call stopped due to an uncaught C++
exception, and 'set unwind-on-terminating-exception on' is in
effect.
However, if we don't call normal_stop then we need to call
async_enable_stdin in call_thread_fsm::should_stop. Prior to this
commit this was only done for the case where the inferior function
call completed successfully.
In this commit I now call ::should_notify_stop and use this to
determine if we need to call async_enable_stdin. With this done we
now call async_enable_stdin for each of the three cases listed above,
which means that GDB will exit wait_sync_command_done correctly (see
run_inferior_call in infcall.c).
With these two changes the problem is mostly resolved. However, the
solution isn't ideal, we've still lost some information.
Here is how GDB 13.1 behaves, this is before commits b1c0ab20809a and
2e411b8c68eb:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing breakpoint condition:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
In this state we see two stop notifications, the first is where the
signal occurred, while the second is where the breakpoint is located.
As GDB has unwound the stack (thanks to unwindonsignal) the second
stop notification reflects where the inferior is actually located.
Then after commits b1c0ab20809a and 2e411b8c68eb the behaviour changed
to this:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Program received signal SIGSEGV, Segmentation fault.
0x0000000000401116 in cond_fail () at /tmp/mi-condbreak-fail.c:24
24 return *p; /* Crash here. */
Error in testing condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
(gdb) bt 1
#0 foo () at /tmp/mi-condbreak-fail.c:30
(More stack frames follow...)
(gdb)
This is the broken state. GDB is reports the SIGSEGV location, but
not the unwound breakpoint location. The final 'bt 1' shows that the
inferior is not located in cond_fail, which is the only location GDB
reported, so this is clearly wrong.
After implementing the fixes described above we now get this
behaviour:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing breakpoint condition for breakpoint 1:
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better. GDB now reports a single stop at the location of the
breakpoint, which is where the inferior is actually located. However,
by removing the first stop notification we have lost some potentially
useful information about which signal caused the inferior to stop.
To address this I've reworked the message that is printed to include
the signal information. GDB now reports this:
$ gdb -q /tmp/mi-condbreak-fail \
-ex 'set unwindonsignal on' \
-ex 'break 30 if (cond_fail())' \
-ex 'run'
Reading symbols from /tmp/mi-condbreak-fail...
Breakpoint 1 at 0x40111e: file /tmp/mi-condbreak-fail.c, line 30.
Starting program: /tmp/mi-condbreak-fail
Error in testing condition for breakpoint 1:
The program being debugged received signal SIGSEGV, Segmentation fault
while in a function called from GDB. GDB has restored the context
to what it was before the call. To change this behavior use
"set unwindonsignal off". Evaluation of the expression containing
the function (cond_fail) will be abandoned.
Breakpoint 1, foo () at /tmp/mi-condbreak-fail.c:30
30 global_counter += 1; /* Set breakpoint here. */
(gdb)
This is better, the user now sees a single stop notification at the
correct location, and the error message describes which signal caused
the inferior function call to stop.
However, we have lost the information about where the signal
occurred. I did consider trying to include this information in the
error message, but, in the end, I opted not too. I wasn't sure it was
worth the effort. If the user has selected to unwind on signal, then
surely this implies they maybe aren't interested in debugging failed
inferior calls, so, hopefully, just knowing the signal name will be
enough. I figure we can always add this information in later if
there's a demand for it.
|
|
New helper proc mi_info_frame which takes care of running the MI
-stack-info-frame command and matching its output.
Like the breakpoint helper procs, this new proc takes a name/value
argument list and uses this to build the expected result regexp. This
means that we can now write something like:
mi_info_frame "test name here" \
-level 0 -func name -line 123
Instead of the current equivalent:
mi_gdb_test "235-stack-info-frame" \
"235\\^done,frame=\{level=\"0\",addr=\"$hex\",func=\"name\",file=\".*\",fullname=\".*\",line=\"123\",arch=\".*\"\}" \
"test name here"
There's also a helper proc mi_make_info_frame_regexp which is
responsible for building the 'frame={...}' part of the pattern.
I've update the two existing tests that use -stack-info-frame and
expect the command to succeed. There is another test that runs
-stack-info-frame and expects the command to fail -- the helper proc
doesn't help with this case, so that test is not changed.
|
|
Currently, each target backend is responsible for printing "[Thread
...exited]" before deleting a thread. This leads to unnecessary
differences between targets, like e.g. with the remote target, we
never print such messages, even though we do print "[New Thread ...]".
E.g., debugging the gdb.threads/attach-many-short-lived-threads.exp
with gdbserver, letting it run for a bit, and then pressing Ctrl-C, we
currently see:
(gdb) c
Continuing.
^C[New Thread 3850398.3887449]
[New Thread 3850398.3887500]
[New Thread 3850398.3887551]
[New Thread 3850398.3887602]
[New Thread 3850398.3887653]
...
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb)
Above, we only see "New Thread" notifications, even though threads
were deleted.
After this patch, we'll see:
(gdb) c
Continuing.
^C[Thread 3558643.3577053 exited]
[Thread 3558643.3577104 exited]
[Thread 3558643.3577155 exited]
[Thread 3558643.3579603 exited]
...
[New Thread 3558643.3597415]
[New Thread 3558643.3600015]
[New Thread 3558643.3599965]
...
Thread 1 "attach-many-sho" received signal SIGINT, Interrupt.
0x00007ffff7e6a23f in __GI___clock_nanosleep (clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7fffffffda80, rem=rem@entry=0x7fffffffda80)
at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:78
78 in ../sysdeps/unix/sysv/linux/clock_nanosleep.c
(gdb) q
This commit fixes this by moving the thread exit printing to common
code instead, triggered from within delete_thread (or rather,
set_thread_exited).
There's one wrinkle, though. While most targest want to print:
[Thread ... exited]
the Windows target wants to print:
[Thread ... exited with code <exit_code>]
... and sometimes wants to suppress the notification for the main
thread. To address that, this commits adds a delete_thread_with_code
function, only used by that target (so far).
This fix was originally posted as part of a larger series:
https://inbox.sourceware.org/gdb-patches/20221212203101.1034916-1-pedro@palves.net/
But didn't really need to be part of that series. In order to get
this fix merged sooner, I (Andrew Burgess) have rebased this commit
outside of the original series. Any bugs introduced while splitting
this patch out and rebasing, are entirely my own.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30129
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
|
|
In this commit:
commit b080fe54fb3414b488b8ef323c6c50def061f918
Date: Tue Nov 8 12:32:51 2022 +0000
gdb: add inferior-specific breakpoints
limited support was added in lib/mi-support.exp to help with testing
of inferior specific breakpoints.
Though the changes that were added were not wrong, while working on a
later patch, I realised that I had added the support in the wrong
place -- I only added support to mi_make_breakpoint_multi, when really
I should have added the support to mi_make_breakpoint_1, which is used
by all of the MI procs that create breakpoints.
This commit moves the support to mi_make_breakpoint_1, and updates all
the procs that use mi_make_breakpoint_1 to accept, and then pass
through, and (optional) inferior argument. This will make it much
easier to write MI tests for inferior specific breakpoints.
There's no change in what is tested after this commit.
|
|
The commit:
commit b080fe54fb3414b488b8ef323c6c50def061f918
Date: Tue Nov 8 12:32:51 2022 +0000
gdb: add inferior-specific breakpoints
introduced a bug in the function breakpoint_set_inferior. The above
commit includes this line:
gdb::observers::breakpoint_modified.notify (b);
when it should have instead used this line:
notify_breakpoint_modified (b);
The change to use notify_breakpoint_modified was introduced to GDB
after commit b080fe54fb34 was written, but before it was merged, and I
failed to update this part of the code during the rebase.
The consequence of this error is that the MI interpreter will not emit
breakpoint-modified notifications when breakpoint_set_inferior is
called.
In this commit I update the code to call notify_breakpoint_modified,
and add a test that checks the MI events are being emitted correctly
in this case.
|
|
This commit extends the breakpoint mechanism to allow for inferior
specific breakpoints (but not watchpoints in this commit).
As GDB gains better support for multiple connections, and so for
running multiple (possibly unrelated) inferiors, then it is not hard
to imagine that a user might wish to create breakpoints that apply to
any thread in a single inferior. To achieve this currently, the user
would need to create a condition possibly making use of the $_inferior
convenience variable, which, though functional, isn't the most user
friendly.
This commit adds a new 'inferior' keyword that allows for the creation
of inferior specific breakpoints.
Inferior specific breakpoints are automatically deleted when the
associated inferior is removed from GDB, this is similar to how
thread-specific breakpoints are deleted when the associated thread is
deleted.
Watchpoints are already per-program-space, which in most cases mean
watchpoints are already inferior specific. There is a small window
where inferior-specific watchpoints might make sense, which is after a
vfork, when two processes are sharing the same address space.
However, I'm leaving that as an exercise for another day. For now,
attempting to use the inferior keyword with a watchpoint will give an
error, like this:
(gdb) watch a8 inferior 1
Cannot use 'inferior' keyword with watchpoints
A final note on the implementation: currently, inferior specific
breakpoints, like thread-specific breakpoints, are inserted into every
inferior, GDB then checks once the inferior stops if we are in the
correct thread or inferior, and resumes automatically if we stopped in
the wrong thread/inferior.
An obvious optimisation here is to only insert breakpoint locations
into the specific program space (which mostly means inferior) that
contains either the inferior or thread we are interested in. This
would reduce the number times GDB has to stop and then resume again in
a multi-inferior setup.
I have a series on the mailing list[1] that implements this
optimisation for thread-specific breakpoints. Once this series has
landed I'll update that series to also handle inferior specific
breakpoints in the same way. For now, inferior specific breakpoints
are just slightly less optimal, but this is no different to
thread-specific breakpoints in a multi-inferior debug session, so I
don't see this as a huge problem.
[1] https://inbox.sourceware.org/gdb-patches/cover.1685479504.git.aburgess@redhat.com/
|
|
When running test-case gdb.base/vfork-follow-parent.exp, I run into:
...
ERROR: tcl error sourcing gdb/testsuite/gdb.base/vfork-follow-parent.exp.
ERROR: error copying "vforked-prog": no such file or directory
while executing
"file copy -force $fromfile $tofile"
(procedure "gdb_remote_download" line 29)
invoked from within
"gdb_remote_download target $binfile3"
...
Fix this by:
- making the copy-to-remote conditional on is_remote target, and
- allowing gdb_remote_download to find $binfile3 by using
standard_output_file.
Also remove unused variable remote_exec_prog.
Tested on x86_64-linux.
|
|
While working on a dwarf assembly test-case I accidentally created the
following pathological dwarf:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xbe>
...
and noticed gdb segfaulting during cooked index creating due to running out of
stack. This is a regression from gdb-12, where gdb just hung.
Fix this by inhibiting the scan_attributes self-recursion for self-references.
The same test-case with -readnow makes gdb hang, so also fix this in
dwarf2_attr and follow_die_ref.
Note that this doesn't fix the same problems for the more complicated case of:
...
<1><be>: Abbrev Number: 3 (DW_TAG_class_type)
<bf> DW_AT_name : c1
<c2> DW_AT_specification: <0xc6>
<1><c6>: Abbrev Number: 4 (DW_TAG_class_type)
<c7> DW_AT_name : c2
<ca> DW_AT_specification: <0xbe>
...
but the approach for deciding whether to fix pathological dwarf cases is as
per PR27981 comment 3:
...
yes if it is cheap/obvious, and no if it is something complicated or expensive.
...
and at this point I'm not sure whether fixing this will fall in the first
category.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I found an obvious bug in Ada aggregate expression handling:
if (vvo != nullptr)
error (_("Invalid record component association."));
name = vvo->get_symbol ()->natural_name ();
Here the code errors when vvo is not null -- and then proceeds to use
vvo.
This hasn't caused a crash because, I believe, there's currently no
way to reach this code in the null case. However, I'm not really
willing to assert this...
Fixing this shows another bug, which is that due to the way the parser
works, a field name in an aggregate expression might erroneously be
fully qualified if some global variable with the same base name
exists.
The included test case triggers both bugs. Note that the test
includes a confounding case for array aggregates as well, but as these
are harder to fix, I've left it as kfail.
As this is Ada-specific, and has already been tested internally at
AdaCore, I am checking it in.
|
|
DAP specifies an event that should be sent when a module is removed.
This patch implements this.
Tested-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I ran into a test failure on gdb.python/py-thread-exited.c. The test
creates two threads and then catches the thread exits in Python. The
test expects the threads to exit in a specific order.
As the test is currently written, it is _likely_, but not guaranteed,
that the threads will exit in the same order they are created, which
is what the test expects.
When running on a loaded system I ran into a case where the threads
exited in the reverse creation order, which caused the test to fail.
I could fix this by having the .exp file not care about the thread
order, or by changing the C file to force the order. I chose the
later, and added a pthread_barrier_t to ensure the threads exit in the
correct order.
There should be no change in what is tested after this commit.
|
|
It was pointed out on the mailing list[1] that after this commit:
commit b1e0126ec56e099d753c20e91a9f8623aabd6b46
Date: Wed Jun 21 14:18:54 2023 +0100
gdb: don't resume vfork parent while child is still running
the test gdb.base/vfork-follow-parent.exp now has some failures when
run with the native-gdbserver or native-extended-gdbserver boards:
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to end of inferior 2 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: inferior 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: print unblock_parent = 1 (timeout)
FAIL: gdb.base/vfork-follow-parent.exp: resolution_method=schedule-multiple: continue to break_parent (timeout)
The reason that these failures don't show up when run on the standard
unix board is that the test is only run in the default operating mode,
so for Linux this will be all-stop on top of non-stop.
If we adjust the test script so that it runs in the default mode and
with target-non-stop turned off, then we see the same failures on the
unix board. This commit includes this change.
The way that the test is written means that it is not (currently)
possible to turn on non-stop mode and have the test still work, so
this commit does not do that.
I have also updated the test script so that the vfork child performs
an exec as well as the current exit. Exec and exit are the two ways
in which a vfork child can release the vfork parent, so testing both
of these cases is useful I think.
In this test the inferior performs a vfork and the vfork-child
immediately exits. The vfork-parent will wait for the vfork-child and
then blocks waiting for gdb. Once gdb has released the vfork-parent,
the vfork-parent also exits.
In the test that fails, GDB sets 'detach-on-fork off' and then runs to
the vfork. At this point the test tries to just "continue", but this
fails as the vfork-parent is still selected, and the parent can't
continue until the vfork-child completes. As the vfork-child is
stopped by GDB the parent will never stop once resumed, so GDB refuses
to resume it.
The test script then sets 'schedule-multiple on' and once again
continues. This time GDB, in theory, resumes both the parent and the
child, the parent will be held blocked by the kernel, but the child
will run until it exits, and which point GDB stops again, this time
with inferior 2, the newly exited vfork-child, selected.
What happens after this in the test script is irrelevant as far as
this failure is concerned.
To understand why the test started failing we should consider the
behaviour of four different cases:
1. All-stop-on-non-stop before commit b1e0126ec56e,
2. All-stop-on-non-stop after commit b1e0126ec56e,
3. All-stop-on-all-stop before commit b1e0126ec56e, and
4. All-stop-on-all-stop after commit b1e0126ec56e.
Only case #4 is failing after commit b1e0126ec56e, but I think the
other cases are interesting because, (a) they inform how we might fix
the regression, and (b) it turns out the behaviour of #2 changed too
with the commit, but the change was harmless.
For #1 All-stop-on-non-stop before commit b1e0126ec56e, what happens
is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-non-stop, every thread is resumed
individually, so GDB tries to resume both the vfork-parent and the
vfork-child, both of which succeed,
3. The vfork-parent is held stopped by the kernel,
4. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
5. At this point we might take two paths depending on which event
GDB handles first, if GDB handles the VFORK_DONE first then:
(a) As GDB is controlling both parent and child the VFORK_DONE is
ignored (see handle_vfork_done), the vfork-parent will be
resumed,
(b) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
Alternatively, if GDB selects the EXITED event first then:
(c) GDB processes the EXITED event, selects the (now defunct)
vfork-child, and stops, returning control to the user.
(d) At some future time the user resumes the vfork-parent, at
which point the VFORK_DONE is reported to GDB, however, GDB
is ignoring the VFORK_DONE (see handle_vfork_done), so the
parent is resumed.
For case #2, all-stop-on-non-stop after commit b1e0126ec56e, the
important difference is in step (2) above, now, instead of resuming
both the vfork-parent and the vfork-child, only the vfork-child is
resumed. As such, when we get to step (5), only a single event, the
EXITED event is reported.
GDB handles the EXITED just as in (5)(c), then, later, when the user
resumes the vfork-parent, the VFORKED_DONE is immediately delivered
from the kernel, but this is ignored just as in (5)(d), and so,
though the pattern of when the vfork-parent is resumed changes, the
overall pattern of which events are reported and when, doesn't
actually change. In fact, by not resuming the vfork-parent, the order
of events (in this test) is now deterministic, which (maybe?) is a
good thing.
If we now consider case #3, all-stop-on-all-stop before commit
b1e0126ec56e, then what happens is:
1. GDB calls proceed with the vfork-parent selected, as schedule
multiple is on user_visible_resume_ptid returns -1 (everything)
as the resume_ptid (see proceed function),
2. As this is all-stop-on-all-stop, the resume is passed down to the
linux-nat target, the vfork-parent is the event thread, while the
vfork-child is a sibling of the event thread,
3. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this causes the vfork-child to be resumed. Then
in linux_nat_target::resume, the event thread, the vfork-parent,
is also resumed.
4. The vfork-parent is held stopped by the kernel,
5. The vfork-child completes (exits) at which point the GDB sees the
EXITED event for the vfork-child and the VFORK_DONE event for the
vfork-parent,
6. We are now in a situation identical to step (5) as for
all-stop-on-non-stop above, GDB selects one of the events to
handle, and whichever we select the user sees the correct
behaviour.
And so, finally, we can consider #4, all-stop-on-all-stop after commit
b1e0126ec56e, this is the case that started failing.
We start out just like above, in proceed, the resume_ptid is
-1 (resume everything), due to schedule multiple being on. And just
like above, due to the target being all-stop, we call
proceed_resume_thread_checked just once, for the current thread,
which, remember, is the vfork-parent thread.
The change in commit b1e0126ec56e was to avoid resuming a vfork-parent
thread, read the commit message for the justification for this change.
However, this means that GDB now rejects resuming the vfork-parent in
this case, which means that nothing gets resumed! Obviously, if
nothing resumes, then nothing will ever stop, and so GDB appears to
hang.
I considered a couple of solutions which, in the end, I didn't go
with, these were:
1. Move the vfork-parent check out of proceed_resume_thread_checked,
and place it in proceed, but only on the all-stop-on-non-stop
path, this should still address the issue seen in b1e0126ec56e,
but would avoid the issue seen here. I rejected this just
because it didn't feel great to split the checks that exist in
proceed_resume_thread_checked like this,
2. Extend the condition in proceed_resume_thread_checked by adding a
target_is_non_stop_p check. This would have the same effect as
idea 1, but leaves all the checks in the same place, which I
think would be better, but this still just didn't feel right to
me, and so,
What I noticed was that for the all-stop-on-non-stop, after commit
b1e0126ec56e, we only resumed the vfork-child, and this seems fine.
The vfork-parent isn't going to run anyway (the kernel will hold it
back), so if feels like we there's no harm in just waiting for the
child to complete, and then resuming the parent.
So then I started looking at follow_fork, which is called from the top
of proceed. This function already has the task of switching between
the parent and child based on which the user wishes to follow. So, I
wondered, could we use this to switch to the vfork-child in the case
that we are attached to both?
Turns out this is pretty simple to do.
Having done that, now the process is for all-stop-on-all-stop after
commit b1e0126ec56e, and with this new fix is:
1. GDB calls proceed with the vfork-parent selected, but,
2. In follow_fork, and follow_fork_inferior, GDB switches the
selected thread to be that of the vfork-child,
3. Back in proceed user_visible_resume_ptid returns -1 (everything)
as the resume_ptid still, but now,
4. When GDB calls proceed_resume_thread_checked, the vfork-child is
the current selected thread, this is not a vfork-parent, and so
GDB allows the proceed to continue to the linux-nat target,
5. In linux_nat_target::resume, GDB calls linux_nat_resume_callback
for all threads, this does not resume the vfork-parent (because
it is a vfork-parent), and then the vfork-child is resumed as
this is the event thread,
At this point we are back in the same situation as for
all-stop-on-non-stop after commit b1e0126ec56e, that is, the
vfork-child is resumed, while the vfork-parent is held stopped by
GDB.
Eventually the vfork-child will exit or exec, at which point the
vfork-parent will be resumed.
[1] https://inbox.sourceware.org/gdb-patches/3e1e1db0-13d9-dd32-b4bb-051149ae6e76@simark.ca/
|
|
Fixes the issue where jump failed if multiple inferiors run the same
source.
See the below example
$ gdb -q ./simple
Reading symbols from ./simple...
(gdb) break 2
Breakpoint 1 at 0x114e: file simple.c, line 2.
(gdb) run
Starting program: /temp/simple
Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) add-inferior
[New inferior 2]
Added inferior 2 on connection 1 (native)
(gdb) inferior 2
[Switching to inferior 2 [<null>] (<noexec>)]
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 <null> 1 (native)
(gdb) file ./simple
Reading symbols from ./simple...
(gdb) run
Starting program: /temp/simple
Thread 2.1 "simple" hit Breakpoint 1, main () at simple.c:2
2 int a = 42;
(gdb) info inferiors
Num Description Connection Executable
1 process 6250 1 (native) /temp/simple
* 2 process 6705 1 (native) /temp/simple
(gdb) jump 3
Unreasonable jump request
(gdb)
In this example, jump fails because the debugger finds two different
locations, one for each inferior.
Solution is to limit the search to the current program space.
This is done by having the jump_command function use
decode_line_with_current_source rather than
decode_line_with_last_displayed, which makes sense,
the *_current_source function always looks up a location based on the
current thread's location -- if a user is asking the current thread to
jump, then surely their destination should be relative to where the
current thread is located.
Then, inside decode_line_with_current_source, the call to
decode_line_1 is updated to pass through the current program_space,
which will limit the returned locations to those in the current
program space.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
resume_stopped_resumed_lwps
At the moment, while performing a software single-step, gdbserver fails
to reinsert software single-step breakpoints for a LWP when
interrupted by a signal in another thread. This commit fixes this
problem by reinstalling software single-step breakpoints in
linux_process_target::resume_stopped_resumed_lwps in
gdbserver/linux-low.cc.
This bug was discovered due to a failing assert in maybe_hw_step()
in gdbserver/linux-low.cc. Looking at the backtrace revealed
that the caller was linux_process_target::resume_stopped_resumed_lwps.
I was uncertain whether the assert should still be valid when called
from that method, so I tried hoisting the assert from maybe_hw_step
to all callers except resume_stopped_resumed_lwps. But running the
new test case, described below, showed that merely eliminating the
assert for this case was NOT a good fix - a study of the log file for
the test showed that the single-step operation failed to occur.
Instead GDB (via gdbserver) stopped at the next breakpoint that was
hit.
Zhiyong Yan had proposed a fix which resinserted software single-step
breakpoints, albeit at a different location in linux-low.cc. Testing
revealed that, while running gdb.threads/pending-fork-event-detach,
the executable associated with that test would die due to a SIGTRAP
after the test program was detached. Examination of the core file(s)
showed that a breakpoint instruction had been left in program memory.
Test results were otherwise very good, so Zhiyong was definitely on
the right track!
This commit causes software single-step breakpoint(s) to be inserted
before the call to maybe_hw_step in resume_stopped_resumed_lwps. This
will cause 'has_single_step_breakpoints (thread)' to be true, so that
the assert in maybe_hw_step...
/* GDBserver must insert single-step breakpoint for software
single step. */
gdb_assert (has_single_step_breakpoints (thread));
...will no longer fail. And better still, the single-step breakpoints
are reinstalled, so that stepping will actually work, even when
interrupted.
The C code for the test case was loosely adapted from the reproducer
provided in Zhiyong's bug report for this problem. The .exp file was
copied from next-fork-other-thread.exp and then tweaked slightly. As
noted in a comment in next-fork-exec-other-thread.exp, I had to remove
"on" from the loop for non-stop as it was failing on all architectures
(including x86-64) that I tested. I have a feeling that it ought to
work, but this can be investigated separately and (re)enabled once it
works. I also increased the number of iterations for the loop running
the "next" commands. I've had some test runs which don't show the bug
until the loop counter exceeded 100 iterations. The C file for the
new test uses shorter delays than next-fork-other-thread.c though, so
it doesn't take overly long (IMO) to run this new test.
Running the new test on a Raspberry Pi w/ a 32-bit (Arm) kernel and
userland using a gdbserver build without the fix in this commit shows
the following results:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=12: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=9: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=18: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=3: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=11: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=fork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=on: i=3: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=auto: non-stop=off: displaced-stepping=off: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=47: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=57: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=auto: i=1: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=on: i=10: next to break here
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=off: non-stop=off: displaced-stepping=off: i=1: next to break here
=== gdb Summary ===
# of unexpected core files 12
# of expected passes 3011
# of unexpected failures 14
Each of the 12 core files were caused by the failed assertion in
maybe_hw_step in linux-low.c. These correspond to 12 of the
unexpected failures.
When the tests are run using a gdbserver build which includes the fix
in this commit, the results are significantly better, but not perfect:
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=auto: i=143: next to other line
FAIL: gdb.threads/next-fork-exec-other-thread.exp: fork_func=vfork: target-non-stop=on: non-stop=off: displaced-stepping=on: i=25: next to other line
=== gdb Summary ===
# of expected passes 10178
# of unexpected failures 2
I think that the two remaining failures are due to some different
problem. They are also racy - I've seen runs with no failures or only
one failure, but never more than two. Also, those runs were conducted
with the loop count in next-fork-exec-other-thread.exp set to 200.
During his testing of this fix and the new test case, Luis Machado
found that this test was taking a long time and asked about ways to
speed it up. I then conducted additional tests in which I gradually
reduced the loop count, timing each one, also noting the number of
failures. With the loop count set to 30, I found that I could still
reliably reproduce the failures that Zhiyong reported (in which, with
the proper settings, core files are created). But, with the loop
count set to 30, the other failures noted above were much less likely
to show up. Anyone wishing to investigate those other failures should
set the loop count back up to 200.
Running the new test on x86-64 and aarch64, both native and
native-gdbserver shows no failures.
Also, I see no regressions when running the entire test suite for
armv7l-unknown-linux-gnueabihf (i.e. the Raspberry Pi w/ 32-bit
kernel+userland) with --target_board=native-gdbserver. Additionally,
using --target_board=native-gdbserver, I also see no regressions for
the entire test suite for x86-64 and aarch64 running Fedora 38.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30387
Co-Authored-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Zhiyong Yan <zhiyong.yan@windriver.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
The NUMCHILD value for the "A_String_Access" test differs for X86 and
PowerPC. The patch substitutes $decimal instead of "1" to match the value
of NUMCHILD.
The test "-var-update A_String_Access" generates different output depending
on the value of VAROBJ_UPDATE_RESULT.TYPE_CHANGED. If the value is true,
the strings "new_type" and "new_num_children" are printed along with their
values.
The VAROBJ_UPDATE_RESULT.TYPE_CHANGED value is true on PowerPC which
produces the output:
Expecting: ^(-var-update A_String_Access[
]+)?(\^done,changelist=\[\{name="A_String_Access",in_scope="true",type_changed="false",has_more="0"\}\][
]+[(]gdb[)]
[ ]*)
-var-update A_String_Access
^done,changelist=[{name="A_String_Access",in_scope="true",type_changed="true",new_type="pck.string_access",new_num_children="1",has_more="0"}]
(gdb)
FAIL: gdb.ada/mi_var_access.exp: update at stop 2 (unexpected output)
The patch adds a second possible result string for the test
$re_varobj_update_result_type to match the case when type_changed is true.
Currently for the mi_var_access.exp test VAROBJ_UPDATE_RESULT.TYPE_CHANGED
is true on PowerPC and false on X86-64.
Fixes 2 failures on PowerPC.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While working on a GNAT bug, I wanted to also test
arr_acc_idx_w_gap.exp using GNAT encodings. When the GNAT change is
ready, I plan to add a new case here.
Tested on x86-64 Fedora 36. I am checking this in.
|
|
Test-case gdb.dwarf2/pr13961.exp contains:
...
<1><25>: Abbrev Number: 8 (DW_TAG_class_type)
<26> DW_AT_specification: <0x2a>
<1><2a>: Abbrev Number: 2 (DW_TAG_class_type)
<2b> DW_AT_name : foo
<2f> DW_AT_byte_size : 4
<30> DW_AT_decl_file : 1
<31> DW_AT_decl_line : 1
<32> DW_AT_sibling : <0x44>
...
The DIE at 0x25 contains an intra-CU forward reference, and is deferred during
DIE indexing in the cooked_index, by adding it to m_deferred_entries.
The resulting cooked index entries are:
...
[25] ((cooked_index_entry *) 0x333b5d0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
[26] ((cooked_index_entry *) 0x333b630)
name: foo
canonical: foo
qualified: foo::foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0x333b5d0) [foo]
...
Notice that 0x2a is the parent of 0x25, and that this is why the qualified
name of 0x25 is "foo::foo", which is incorrect, it's supposed to be "foo".
The parent is set here in cooked_indexer::make_index:
...
for (const auto &entry : m_deferred_entries)
{
void *obj = m_die_range_map.find (entry.spec_offset);
cooked_index_entry *parent = static_cast<cooked_index_entry *> (obj);
m_index_storage->add (entry.die_offset, entry.tag, entry.flags,
entry.name, parent, m_per_cu);
}
...
and AFAICT, we store in m_die_range_map the parent of the respective
spec_offset DIE (though that's not clear from the comment describing it).
So, the root cause of this is that when we lookup the parent for DIE 0x25, we get
m_die_range_map.find (0x2a) == 0x2a.
This is an off-by-one error, fixed in cooked_indexer::recurse by:
...
- CORE_ADDR start = form_addr (parent_entry->die_offset,
+ CORE_ADDR start = form_addr (parent_entry->die_offset + 1,
...
which gives us:
...
[12] ((cooked_index_entry *) 0x41e21f0)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x25
parent: ((cooked_index_entry *) 0)
[13] ((cooked_index_entry *) 0x41e2190)
name: foo
canonical: foo
qualified: foo
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0x2a
parent: ((cooked_index_entry *) 0)
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/30739
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30739
|
|
The frame command on Power pc prints the address in hex between the
#0 and in calle.increment. For example
(gdb) frame
#0 0x0000000010010a88 in callee.increment (val=val@entry=99.0, msg=...)
at /home/.../gdb/testsuite/gdb.ada/O2_float_param/callee.adb:19
19 procedure Increment (Val : in out Float; Msg: String) is
The printing of the address for the frame is done by function
print_frame in gdb/stack.c. If SAL.IS_stmt is false for the frame,
function frame_show_address returns true and print_frame prints the
address. Currently, SAL.IS is false on PowerPC and true on X86-64.
Update the set re string to accept the hex address if it exits.
Fixes two failures on PowerPC.
Patch tested on Power10 with no new regressions.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
gdbserver does not notify gdb of new threads when they are created.
I'm not sure if this is documented anywhere, but it is mentioned on
this page:
https://sourceware.org/gdb/wiki/LocalRemoteFeatureParity
Search for "Finding new threads in the inferior".
This behavior is a bit unfortunate -- I would think that it would be
better to arrange for such notification if something on the gdb side
is interested.
Meanwhile, this patch fixes py-thread-exited.exp to work around this
problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30677
|
|
cc-with-gnu-debuglink
When running test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-gnu-debuglink, I run into:
...
(gdb) PASS: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo
maint print symbols -objfile enqueued-cu-base-addr^M
(gdb) FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The problem is that the CU we're trying to print is in objfile
enqueued-cu-base-addr.debug instead of enqueued-cu-base-addr.
Fix this by replacing "-objfile enqueued-cu-base-addr" with "-source cu2".
Tested on x86_64-linux.
|
|
I ran test-case gdb.dwarf2/enqueued-cu-base-addr.exp with target board
cc-with-debug-names, and ran into:
...
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: ptype foo (GDB internal error)
FAIL: gdb.dwarf2/enqueued-cu-base-addr.exp: CU addr found
...
The first FAIL is a known issue, PR symtab/29572.
The following FAIL is a consequence of the first FAIL, so require for the
second test that the first test passes.
Tested on x86_64-linux, with target boards unix and cc-with-debug-names.
|
|
When testing current gdb trunk on Solaris/amd64, the whole session was
reliably terminated by make check. I could trace this to the following
entry in gdb.arch/amd64-disp-step/gdb.log:
FAIL: gdb.arch/amd64-disp-step.exp: add into rcx: send_signal=on: get
inferior pid
Executing on target: kill -ALRM -1 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -ALRM -1
If $inferior_pid doesn't refer to a single process for some reason, this
kill would terminate either a process group or the whole session.
This patch avoids this by ensuring that the pid arg is positive.
Tested on amd64-pc-solaris2.11 and x86_64-pc-linux-gnu.
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Fortran allows variables and function to be named after language defined
intrinsics as they are not reserved keywords. For example, the abs maths
intrinsic can be hidden by a user declaring a variable called abs.
The behavior before this patch was to favour the intrinsic, which meant
that any variables named, for example "allocated", could not be
inspected by GDB.
This patch inverts this priority to bring GDB's behaviour closer to the
Fortran language, where the user defined symbol can hide the intrinsic.
Special care was need to prevent any C symbols from overriding either
Fortran intrinsics or user defined variables. This was observed to be
the case when GDB has access to symbols for abs from libm. This was
solved by only allowing symbols not marked with language_fortran to be
overridden.
In total this brings the order of precedence to the following (highest
first):
1. User defined Fortran variable or function.
2. Fortran intrinsic.
3. Symbols from languages other than Fortran.
The sizeof intrinsic is now case insensitive. This is closer to the
Fortran language. I believe this change is safe enough as it increases
the acceptance of the grammar, rather than restricts it. I.e. it should
not break any existing scripts which rely on it. Unless of course they
rely on SIZEOF being rejected.
GDB built with GCC 13.
No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel
LLVM, NVHPC; Platforms: x86_64, aarch64.
Existing tests in gdb.fortran cover the invocation of intrinsics
including: intrinsics.exp, shape.exp, rank.exp, lbound-ubound.exp.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When loading an executable using "file a.out", the language is set according
to a.out, which can involve looking up the language of symbol "main", which
will cause the symtab expansion for the containing CU.
Expansion of lto debug info can be slow, so in commit d3214198119 ("[gdb] Use
partial symbol table to find language for main") a feature was added to avoid
the symtab expansion.
This feature stopped working after commit 7f4307436fd ("Fix "start" for D,
Rust, etc").
[ The commit addresses problems related to command start, which requires finding
the main function:
- for language D, "main" was found instead of "D main", and
- for Rust, the correct function was found, but attributed the wrong name
(not fully qualified). ]
Reimplement the feature by adding
cooked_index_functions::lookup_global_symbol_language.
Tested on x86_64-linux.
PR symtab/30661
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30661
|
|
A local gdb test failed with this error message:
Remote communication error. Target disconnected.: Arg list too long.
The ".:" seemed weird to me. This patch removes the ".".
Reviewed-by: John Baldwin <jhb@FreeBSD.org>
|
|
Add lookup of a non-existing symbol to test-case gdb.base/index-cache.exp.
This serves as regression test for PR symtab/30718.
PR symtab/30718
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30718
|
|
gdb.base/index-cache.exp
In test-case gdb.base/index-cache.exp proc run_test_with_flags contains:
...
clean_restart ${testfile}
# The tests generally want to check the cache, so make sure it
# has completed its work.
gdb_test_no_output "maintenance wait-for-index-cache"
...
This however hides data races between:
- index-cache writing (due to file $exec), and
- symbol lookups (due to subsequent ptype commands).
Fix this by:
- moving the "maintenance wait-for-index-cache" to proc check_cache_stats, and
- moving all calls to proc check_cache_stats ALAP.
Tested on x86_64-linux.
|
|
The test-case gdb.base/index-cache.exp uses only one source file, which
contains main.
While doing "file $exec", in set_initial_language a symbol lookup of "main" is
done, causing the symtab containing main to be expanded.
Handling of main is special, and a future optimization may skip the lookup and
expansion.
Reliably exercise:
- the lookup of main, expanding the symtab containing main, by doing
"ptype main", and
- the lookup of another symbol, expanding a symtab not containing main, by:
- adding another source file containing function foo, and
- doing "ptype foo".
This triggered a segfault with target board native-extended-gdbserver, filed
as PR symtab/30712, but that seems to be fixed by a previous commit in this
series.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30712
|
|
Attempting to test the gdb.compile with clang as the compiler results in
over 300 unexpected errors, due to a segmentation fault and several
handshake failures. Since the whole feature is designed around a gcc
plugin, and even the gcc testing is shaky at best, this commit restricts
those tests to only running under gcc. If that gets fixed, this commit
can be reverted.
Approved-By: Tom Tromey <tom@tromey.com>
|
