| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The other day on irc, we were discussing the "m_line" hack in
tui-out.c, and I mentioned that it would be nice to replace this with
a new ui_out_flag.
Later, I looked at ui_out_flag and found:
ui_source_list = (1 << 0),
... and sure enough, this is tested already.
This patch removes tui-out.[ch] and changes the TUI to use an ordinary
cli-out object without this flag set.
As far as I can tell, this doesn't affect behavior at all -- the TUI
tests all pass, and interactively I tried switching stack frames,
"list", etc, and it all seems to work.
New in v2: fixed the problem pointed out by Keith, and added a test
case for that scenario.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
|
|
aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in
configure.ac, so there's no need to pass `-I ../config` here.
Passing `-I ../config` is actually annoying, because it makes the output
different between when the update is triggered by the maintainer mode
and when aclocal or autoreconf is ran with no special flags. The
difference in the output is due to the order of include paths being
different.
Change-Id: I2c963876516570842f20b4a6a470867e7a941006
Approved-By: Tom Tromey <tom@tromey.com>
|
|
commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically")
caused a regression on a test case in the AdaCore internal test suite.
The issue here is that gdb would try to resolve the type of a dynamic
pointer that happened to be NULL. In this case, the "Location address
is not set." error would end up being thrown from the DWARF expression
evaluator.
I think it makes more sense to special-case NULL pointers and not try
to resolve their target type, as that type can't really be accessed
anyway.
This patch implements this idea, and also adds the missing Ada test
case.
|
|
A Python file in my previous commit (5eb2254a1d1) was formatted with
an older version of black, which gives slightly different results.
Reformat with a newer version of black. This should make our
post-commit testing happy again.
No functional changes in this commit.
|
|
I get some changes when running `autoreconf -vf` in the gdb directory,
fix that.
I did a bisect, it appears to have been introduced in this commit, not
sure why we haven't spotted that before.
commit 862776f26a59516467c98091994c3dac90383159
Author: Arsen Arsenovi? <arsen@aarsen.me>
AuthorDate: Wed Nov 15 12:53:04 2023 +0000
Commit: Nick Clifton <nickc@redhat.com>
CommitDate: Wed Nov 15 12:53:04 2023 +0000
Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9
|
|
When we improved error messages in
cd393cec3ab gdb, btrace: improve error messages
we cleared the original errno. When the error reason can not be explained
in a more detailed error message, and we fall back to the default error
message, it now gives Success as error.
Restore the original errno to fix that.
|
|
This started with a Red Hat bug report which can be seen here:
https://bugzilla.redhat.com/show_bug.cgi?id=1850710
The problem reported here was using GDB on GNU/Linux for S390, the
user stepped into JIT generated code. As they enter the JIT code GDB
would report 'PC not saved', and this same message would be reported
after each step/stepi.
Additionally, the user had 'set disassemble-next-line on', and once
they entered the JIT code this output was not displayed, nor were any
'display' directives displayed.
The user is not making use of the JIT plugin API to provide debug
information. But that's OK, they aren't expecting any source level
debug here, they are happy to use 'stepi', but the missing 'display'
directives are a problem, as is the constant 'PC not saved' (error)
message.
What is happening here is that as GDB is failing to find any debug
information for the JIT generated code, it is falling back on to the
S390 prologue unwinder to try and unwind frame #0. Unfortunately,
without being able to identify the function boundaries, the S390
prologue scanner can't help much, in fact, it doesn't even suggest an
arbitrary previous $pc value (some targets that use a link-register
will, by default, assume the link-register contains the previous $pc),
instead the S390 will just say, "sorry, I have no previous $pc value".
The result of this is that when GDB tries to find frame #1 we end
throwing an error from frame_unwind_pc (the 'PC not saved' error).
This error is not caught anywhere except at the top-level interpreter
loop, and so we end up skipping all the 'display' directive handling.
While thinking about this, I wondered, could I trigger the same error
using the Python Unwinder API? What happens if a Python unwinder
claims a frame, but then fails to provide a previous $pc value?
Turns out that exactly the same thing happens, which is great, as that
means we now have a way to reproduce this bug on any target. And so
the test included with this patch does just this. I have a Python
unwinder that claims a frame, but doesn't provide any previous
register values.
I then do two tests, first I stop in the claimed frame (i.e. frame #0
is the frame that can't be unwound), I perform a few steps, and check
the backtrace. And second, I stop in a child of the problem
frame (i.e. frame #1 is the frame that can't be unwound), and from
here I check the backtrace.
While all this is going on I have a 'display' directive in place, and
each time GDB stops I check that the display directive triggers.
Additionally, when checking the backtrace, I am checking that the
backtrace finishes with the message 'Backtrace stopped: frame did not
save the PC'.
As for the fix I chose to add a call to frame_unwind_pc directly to
get_prev_frame_always_1. Calling frame_unwind_pc will cache the
unwound $pc value, so this doesn't add much additional work as
immediately after the new frame_unwind_pc call, we call
get_prev_frame_maybe_check_cycle, which actually generates the
previous frame, which will always (I think) require a call to
frame_unwind_pc anyway.
The reason for adding the frame_unwind_pc call into
get_prev_frame_always_1, is that if the frame_unwind_pc call fails we
want to set the frames 'stop_reason', and get_prev_frame_always_1
seems to be the place where this is done, so I wanted to keep the new
stop_reason setting code next to all the existing stop_reason setting
code.
Additionally, once we enter get_prev_frame_maybe_check_cycle we
actually create the previous frame, then, if it turns out that the
previous frame can't be created we need to remove the frame .. this
seemed more complex than just making the check in
get_prev_frame_always_1.
With this fix in place the original S390 bug is fixed, and also the
test added in this commit, that uses the Python API, is also fixed.
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
|
|
The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and
print the names of all functions. However, some of the functions are
from the libc library, and so the test implicitly demanded libc symbols
to be available, and would fail otherwise, as was raised in PR
gdb/31293.
This commit changes it so we only explicitly check for functions that
are not provided by threadcrash.c if they are indeed available.
Tested on arm-linux and x86_64-linux.
Approved-By: Tom de Vries <tdevries@suse.de>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293
|
|
I noticed in gdb.threads/threadcrash.exp that the usage of test_list is
somewhat convoluted.
Simplify the test-case by storing a classification instead of a pattern in
test_list.
Tested on arm-linux and x86_64-linux.
|
|
A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails
to cout the number of threads in the inferior:
...
FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7
FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list]
...
Fix this by getting the convenience variable _inferior_thread_count as opposed
to calculating it based on the output of "info threads".
Tested on arm-linux and x86_64-linux.
Reviewed-By: Lancelot Six <lancelot.six@amd.com>
Approved-By: Tom de Vries <tdevries@suse.de>
[1] https://linaro.atlassian.net/browse/GNU-1120
|
|
With check-readmore, I run into:
...
FAIL: gdb.threads/threadcrash.exp: test_corefile: \
$thread_count == [llength $test_list]
...
The problem is that the clauses in the gdb_test_multiple for
"thread apply all backtrace" intent to match one line, but actually can
match more than one line, and consequently a match for one type of thread can
consume a line that was supposed to match another thread.
For instance, there's this regexp:
...
-re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" {
...
It's limited at the end by \[^\n\]*, meaning the match stops at the end of the
line.
But it doesn't start with a ^, and consequently can match more than one line.
The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at
the start of each pattern, unless it's anchored using a ^.
Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where:
- hs is: \[^\n\]* (horizontal space), and
- eol is (?=\r\n) (look-ahead end-of-line).
It also turned out to be necessary to drop the -lbl switch, and introduce a
corresponding explicit clause. The -lbl clause is placed ALAP, and
consequently allowed the default fail clause to trigger.
Tested on arm-linux and x86_64-linux.
|
|
In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented
gdb_test_multiple:
...
gdb_test_multiple "thread apply all backtrace" \
"Get thread information" -lbl {
-re "#\[0-9\]+\\\?\\\?\[^\n\]*" {
...
Fix this by moving the command into a variable, allowing the
"gdb_test_multiple ... {" to fit on a single 80 chars line.
Tested on arm-linux and x86_64-linux.
|
|
Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated.
Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for
python >= 3.12.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
With python 3.12, I run into:
...
(gdb) PASS: gdb.python/py-block.exp: check variable access
python print (block['nonexistent'])^M
Python Exception <class 'KeyError'>: 'nonexistent'^M
Error occurred in Python: 'nonexistent'^M
(gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable
...
The problem is that that PyErr_Fetch returns a normalized exception, while the
test-case matches the output for an unnormalized exception.
With python 3.6, PyErr_Fetch returns an unnormalized exception, and the
test passes.
Fix this by:
- updating the test-case to match the output for a normalized exception, and
- lazily forcing normalized exceptions using PyErr_NormalizeException.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use
both consistently to get gdbpy_err_fetch members m_error_value and
m_error_type.
Tested on aarch64-linux.
|
|
The background DWARF reader changes introduced a race when writing to
the index cache. The problem here is that constructing the
index_cache_store_context object should only happen on the main
thread, to ensure that the various value captures do not race.
This patch adds an assert to the construct to that effect, and then
arranges for this object to be constructed by the cooked_index_worker
constructor -- which is only invoked on the main thread.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262
|
|
I think it is cleaner for 'store' to be a method on
index_cache_store_context rather than on the global index cache
itself. This patch makes this change.
|
|
This changes index_cache_store_context to also capture the per-BFD
object when it is constructed. This is used when storing to the
cache, and this approach makes the code a little simpler.
|
|
I noticed that index_cache_store_context captures the 'enabled'
setting, but not the index cache directory. This patch makes this
change, which avoids a possible race -- with background reading, the
user could possibly change this directory at the exact moment the
writer examines the variable.
|
|
This renames the private members of index_cache_store_context to start
with "m_".
|
|
A bug report in the DAP specification repository pointed out that it
is typical for DAP implementations to put a function's return value
into the outermost scope.
This patch changes gdb to follow this convention.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
|
|
This patch changes the Python "stop" event emission code to also add
the function return value, if it is known. This happens when the stop
comes from a "finish" command and when the value can be fetched.
The test is in the next patch.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
PR gdb/31260 points out a race introduced by the background reading
changes. If a given objfile is re-opened when it is already being
read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again,
causing the 'dwz_file' to be reset.
This patch fixes the problem by arranging to open the dwz just once:
when the dwarf2_per_bfd object is created.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31260
|
|
This fixes some duplicate test names in gdb.trace/circ.exp when using
native-gdbserver and native-extended-gdbserver boards.
In this test we set the trace buffer size twice. The same test name
was used each time the size was adjusted.
I've fixed this issue by:
1. Creating a new proc, set_trace_buffer_size, which factors out the
code to change the buffer size, and uses test names based on the
size we're setting the buffer too,
2. Calling the new proc each time we want to adjust the buffer size.
After this the duplicate test names are resolved. There should be no
change in what is tested after this commit.
|
|
This commit fixes some duplicate test names in the gdb.trace/
directory when run with the native-gdbserver and
native-extended-gdbserver boards. In this case the duplicates relate
to the calls to gdb_compile_pthreads which emits a fixed PASS message,
as there are two calls to gdb_compile_pthreads we get a duplicate PASS
message.
In both cases the problem is fixed by adding a with_test_prefix around
one of the compilations, however, I've made additional changes to
clean up the tests a little while I was working on them:
1. Switch to use prepare_for_testing instead of
gdb_compile_pthreads. By passing the 'pthreads' option this does
call gdb_compile_pthreads under the hood, but using the standard
compile function is cleaner,
2. Using prepare_for_testing removes the need to call clean_restart
immediately afterwards, so those calls are removed,
3. I removed the unneeded $executable and $expfile globals, where
the $executable global was used I've replaced this with $binfile,
4. When we compile two executables I've now given these different
names so that both exist at the end of the test run,
5. Removed a gdb_reinitialize_dir call, this is covered by
clean_restart,
6. Use gdb_test_no_output where it makes sense.
I now see no duplicate test names when running these test scripts.
There should be no change in what is being tested after this commit.
|
|
There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())"
in find_register_by_number() when gdb connects to gdbserver, this
is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains
10 reserved regs) is different with the number of regs (35, which not
contains 10 reserved regs) in file gdb/features/loongarch/base64.xml.
Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to
keep consistent with the gdb/features/loongarch/base64.xml, and then
define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that
all the reg numbers in regcache are consistent with tdesc reg numbers.
without this patch:
Execute on the target machine:
$ gdbserver 192.168.1.123:5678 ./test
Execute on the host machine:
$ gdb ./test
(gdb) target remote 192.168.1.123:5678
Output on the target machine:
Process ./test created; pid = 67683
Listening on port 5678
Remote debugging from host 192.168.1.136, port 6789
gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected.
find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed.
Output on the host machine:
Remote debugging using 192.168.1.123:5678
Remote connection closed
Signed-off-by: Hui Li <lihui@loongson.cn>
Approved-By: John Baldwin <jhb@FreeBSD.org>
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
In a couple of spots, the TUI tries to center some text in the window.
Andrew noticed that the calculation is done strangely and the text
ends up somewhat to the left of center.
This patch fixes the problem.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31355
|
|
ChangeLog:
* gdb/jit.c: Fix missing word in code comment.
Signed-off-by: Will Hawkins <hawkinsw@obs.cr>
|
|
Today I realized that while the .debug_names writer uses DW_FORM_udata
for the DIE offset, DW_FORM_ref_addr would be more appropriate here.
This patch makes this change.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31361
|
|
When running test-case gdb.dap/pause.exp 100 times in a loop, it passes
100/100.
But if we remove the two "sleep 0.2" from the test-case, we run into
(copied from dap.log and edited for readability):
...
Traceback (most recent call last):
File "startup.py", line 251, in message
def message():
KeyboardInterrupt
Quit
...
This happens as follows.
CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight.
The idea is that this interrupt triggers while in fn here in message (a nested
function of send_gdb_with_response):
...
def message():
try:
val = fn()
result_q.put(val)
except (Exception, KeyboardInterrupt) as e:
result_q.put(e)
...
but instead it triggers outside the try/except.
Fix this by:
- in CancellationHandler, renaming variable in_flight to in_flight_dap_thread,
and adding a variable in_flight_gdb_thread to be able to distinguish when
a request is in flight in the dap thread or the gdb thread.
- adding a wrapper Cancellable to to deal with cancelling the wrapped
event
- using Cancellable in send_gdb and send_gdb_with_response to wrap the posted
event
- in CancellationHandler.cancel, only call gdb.interrupt if
req == self.in_flight_gdb_thread.
This makes the test-case pass 100/100, also when adding the extra stressor of
"taskset -c 0", which makes the fail more likely without the patch.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR dap/31275
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275
|
|
Move functions send_gdb and send_gdb_with_response, as well as class Invoker
to server module.
Separated out to make the following patch easier to read.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro
register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which
adds the tpidruro register, and unconditionally enabled it in
aarch32_create_target_description.
In Linux, the tpidruro register isn't available via ptrace in the 32-bit
kernel but it is available for an aarch32 program running under an arm64
kernel via the ptrace compat interface. This isn't currently implemented
however, which causes GDB on arm-linux with 64-bit kernel to list the
register but show it as unavailable, as reported by Tom de Vries:
$ gdb -q -batch a.out -ex start -ex 'p $tpidruro'
Temporary breakpoint 1 at 0x512
Temporary breakpoint 1, 0xaaaaa512 in main ()
$1 = <unavailable>
Simon Marchi then clarified:
> The only time we should be seeing some "unavailable" registers or memory
> is in the context of tracepoints, for things that are not collected.
> Seeing an unavailable register here is a sign that something is not
> right.
Therefore, disable the TLS feature in aarch32 target descriptions for Linux
and NetBSD targets (the latter also doesn't seem to support accessing
tpidruro either, based on a quick look at arm-netbsd-nat.c).
This patch fixes the following tests:
Running gdb.base/inline-frame-cycle-unwind.exp ...
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5
FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native,
native-gdbserver and native-extended-gdbserver targets with no regressions.
PR tdep/31418
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418
Approved-By: John Baldwin <jhb@FreeBSD.org>
|
|
No functional change
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
gdb.interrupt was introduced to implement DAP request cancellation.
However, because it can be run from another thread, and because I
didn't look deeply enough at the implementation, it turns out to be
racy.
The fix here is to lock accesses to certain globals in extension.c.
Note that this won't work in the case where configure detects that the
C++ compiler doesn't provide thread support. This version of the
patch disables DAP entirely in this situation.
Regression tested on x86-64 Fedora 38. I also ran gdb.dap/pause.exp
in a thread-sanitizer build tree to make sure the reported race is
gone.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31263
|
|
While working on a different patch, I found a couple of simple addrmap
cleanups.
In one case, a forward declaration is no longer needed, as the header
now includes addrmap.h.
In the other, an include of addrmap.h is no longer needed.
Tested by rebuilding.
|
|
This changes the DAP code to explicitly request that gdb exit.
Previously this could cause crashes, but with the previous cleanups,
this should no longer happen.
This also adds a tests that ensures that gdb exits with status 0.
|
|
This changes run-on-main-thread.c to clear 'runnables' in a final
cleanup. This avoids an issue where a pending runnable could require
Python, but be run after the Python interpreter was finalized.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31172
|
|
This removes finalize_values in favor of adding a new final cleanup.
This is safe now that extension languages are explicitly shut down.
|
|
Right now, Python is shut down via a final cleanup. However, it seems
to me that it is better for extension languages to be shut down
explicitly, after all the ordinary final cleanups are run. The main
reason for this is that a subsequent patch adds another case like
finalize_values; and rather than add a series of workarounds for
Python shutdown, it seemed better to let these be done via final
cleanups, and then have Python shutdown itself be the special case.
|
|
This patch rewrites final cleanups to use std::function and otherwise
be more C++-ish.
|
|
Tom de Vries pointed out that the gdb.dap/pause.exp test writes a
Python file but then does not use it. This patch corrects the
oversight.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
The "python" command (and the Python implementation of the gdb
"source" command) does not handle Python exceptions in the same way as
other gdb-facing Python code. In particular, exceptions are turned
into a generic error rather than being routed through
gdbpy_handle_exception, which takes care of converting to 'quit' as
appropriate.
I think this was done this way because PyRun_SimpleFile and friends do
not propagate the Python exception -- they simply indicate that one
occurred.
This patch reimplements these functions to respect the general gdb
convention here. As a bonus, some Windows-specific code can be
removed, as can the _execute_file function.
The bulk of this change is tweaking the test suite to match the new
way that exceptions are displayed. These changes are largely
uninteresting. However, it's worth pointing out the py-error.exp
change. Here, the failure changes because the test changes the host
charset to something that isn't supported by Python. This then
results in a weird error in the new setup.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354
Acked-By: Tom de Vries <tdevries@suse.de>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
python.c has a split string that is missing a space. There's also a
stray backslash in this code.
Reviewed-By: Tom de Vries <tdevries@suse.de>
|
|
Say we do:
...
$ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp"
...
and add a perror at the end of pause.exp:
...
dap_shutdown
+
+perror "foo"
...
We run into:
...
UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb
...
This happens because the perror increases the errcnt, which is not reset at
the end of the test-case, and consequently the first pass in the following
test-case is changed into an unresolved.
Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the
end of the test-case, which does reset the errcnt, but this is with version
1.6.1.
Furthermore, we reset the errcnt in clean_restart, but the pass is produced
before, so that doesn't help either.
Fix this by resetting errcnt and warncnt in default_gdb_init.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31351
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351
|
|
PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by
commit d56fdf1b976 ("Refine Ada overload matching").
Remove the KFAILs for PR ada/30908.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908
|
|
With test-case gdb.python/py-finish-breakpoint.exp, we run into:
...
(gdb) python print (finishbp_default.hit_count)
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Breakpoint 3 is invalid.
Error while executing Python code.
(gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \
check finishBP on default frame has been hit
...
The test producing the pass is:
...
gdb_test "python print (finishbp_default.hit_count)" "1.*" \
"check finishBP on default frame has been hit"
...
so the pass is produced because the 1 in "line 1" matches "1.*".
Temporary breakpoints are removed when hit, and consequently accessing the
hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is
not possible, and as per spec we get a RuntimeError.
So the RuntimeError is correct, and not specific to finish breakpoints.
The test presumably attempts to match:
...
(gdb) python print (finishbp_default.hit_count)
1
...
but most likely this output was never produced by any gdb version.
Fix this by checking whether the finishbp_default breakpoint has hit by
checking that finishbp_default.is_valid() is False.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/31391
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391
|
|
gdb.base/interrupt.exp reveals that inferior input is
broken on Cygwin:
(gdb) continue
Continuing.
talk to me baby
Input/output error <<< BAD
PASS: gdb.base/interrupt.exp: process is alive
a
[Thread 10688.0x2590 exited with code 1]
[Thread 10688.0x248c exited with code 1]
[Thread 10688.0x930 exited with code 1]
[Thread 10688.0x2c98 exited with code 1]
Program terminated with signal SIGHUP, Hangup.
The program no longer exists.
(gdb) FAIL: gdb.base/interrupt.exp: child process ate our char
a
Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior...
(gdb) ERROR: "" is not a unique command name.
The problem is that inflow.c:child_terminal_inferior is failing to put
the inferior in the foreground, because we're passing down the
inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp.
That is fixed by this commit. Afterwards we will get:
(gdb) continue
Continuing.
talk to me baby
PASS: gdb.base/interrupt.exp: process is alive
a
a <<< GOOD
PASS: gdb.base/interrupt.exp: child process ate our char
[New Thread 7236.0x1c58]
Thread 6 received signal SIGINT, Interrupt. <<< new thread spawned for SIGINT
[Switching to Thread 7236.0x1c58]
0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
(gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C
We still have the FAIL seen above because this change has another
consequence. By failing to put the inferior in the foreground
correctly, Ctrl-C was always reaching GDB first. Now that the
inferior is put in the foreground properly, Ctrl-C reaches the
inferior first, which results in a Windows Ctrl-C event, which results
in Windows injecting a new thread in the inferior to report the Ctrl-C
exception => SIGINT. That is, running the test manually:
Before patch:
(gdb) c
Continuing.
[New Thread 2352.0x1f5c]
[New Thread 2352.0x1988]
[New Thread 2352.0x18cc]
<<< Ctrl-C pressed.
Thread 7 received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 2352.0x18cc]
0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb)
Above, GDB got the SIGINT, and it manually passes it down the
inferior, which reaches windows_nat_target::interrupt(), which
interrupts the inferior with DebugBreakProcess (which injects a new
thread in the inferior that executes an int3 instruction).
After this patch, we have (with "set debugexceptions on" so
DBG_CONTROL_C is visible):
(gdb) c
Continuing.
[New Thread 9940.0x1168]
[New Thread 9940.0x5f8]
gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19
[New Thread 9940.0x3d8]
gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b <<< Ctrl-C
Thread 7 received signal SIGINT, Interrupt. <<< new injected thread
[Switching to Thread 9940.0x3d8]
0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll
(gdb)
This new behavior is exactly the same as what you see with a MinGW GDB
build. Also, SIGINT reaching inferior first is what you get on Linux
as well currently.
I wrote an initial fix for this before I discovered that Cygwin
downstream had a similar change, so I then combined the patches. I am
adding a Co-Authored-By for that reason.
Co-Authored-By: Takashi Yano <takashi.yano@nifty.ne.jp>
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f
|
|
arc-analyze-prologue.S test does not contain debug information thus
it must be compiled without -g option. Otherwise GDB will try to
unwind frames using debug information (which does not exist for .S
code!) instead of analyzing frames manually.
Approved-By: Shahab Vahedi <shahab@synopsys.com>
|
|
Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0
|
|
I noticed a spot in ada-lang.c where the return value of
value_as_address was cast to CORE_ADDR -- a no-op cast. I searched
and found another. This patch fixes both.
|
