| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This adds a constructor to signal_catchpoint and simplifies the
caller.
|
|
This adds a constructor to solib_catchpoint and simplifies the caller.
|
|
This adds a constructor to fork_catchpoint and simplifies the caller.
|
|
catch_exec_command_1 clears the new catchpoint's "exec_pathname"
field, but this is already done by virtue of calling "new".
|
|
This constifies breakpoint::print_recreate.
|
|
This constifies breakpoint::print_mention.
|
|
This constifies breakpoint::print_one.
|
|
This constifies breakpoint::print_it. Doing this pointed out some
code in ada-lang.c that can be simplified a little as well.
|
|
works_in_software_mode is only useful for watchpoints. This patch
moves it from breakpoint to watchpoint, and changes it to return bool.
|
|
This changes breakpoint::explains_signal to return bool.
|
|
The breakpoint::ops field is set but never used. This removes it.
|
|
This changes print_recreate_thread to be a method on breakpoint. This
function is only used as a helper by print_recreate methods, so I
thought this transformation made sense.
|
|
The break point after the stepi on Intel is the entry point of the user
signal handler function test_signal_handler. The code at the break point
looks like:
0x<hex address> <test_signal_handler>: endbr64
On PowerPC with a Linux 5.9 kernel or latter, the address where gdb stops
after the stepi is in the vdso code inserted by the kernel. The code at the
breakpoint looks like:
0x<hex address> <__kernel_start_sigtramp_rt64>: bctrl
This is different from other architectures. As discussed below, recent
kernel changes involving the vdso for PowerPC have been made changes to the
signal handler code flow. PowerPC is now stopping in function
__kernel_start_sigtramp_rt64. PowerPC now requires an additional stepi to
reach the user signal handler unlike other architectures.
The bp-permanent.exp and kill-after-signal tests run fine on PowerPC with an
kernel that is older than Linux 5.9.
The PowerPC 64 signal handler was updated by the Linux kernel 5.9-rc1:
commit id: 0138ba5783ae0dcc799ad401a1e8ac8333790df9
powerpc/64/signal: Balance return predictor stack in signal trampoline
An additional change to the PowerPC 64 signal handler was made in Linux
kernel version 5.11-rc7 :
commit id: 24321ac668e452a4942598533d267805f291fdc9
powerpc/64/signal: Fix regression in __kernel_sigtramp_rt64() semantics
The first kernel change, puts code into the user space signal handler (in
the vdso) as a performance optimization to prevent the call/return stack
from getting out of balance. The patch ensures that the entire
user/kernel/vdso cycle is balanced with the addition of the "brctl"
instruction.
The second patch, fixes the semantics of __kernel_sigtramp_rt64(). A new
symbol is introduced to serve as the jump target from the kernel to the
trampoline which now consists of two parts.
The above changes for PowerPC signal handler, causes gdb to stop in the
kernel code not the user signal handler as expected. The kernel dispatches
to the vdso code which in turn calls into the signal handler. PowerPC is
special in that the kernel is using a vdso instruction (bctrl) to enter the
signal handler.
I do not have access to a system with the first patch but not the second. I did
test on Power 9 with the Linux 5.15.0-27-generic kernel. Both tests fail on
this Power 9 system. The two tests also fail on Power 10 with the Linux
5.14.0-70.9.1.el9_0.ppc64le kernel.
The following patch fixes the issue by checking if gdb stopped at "signal
handler called". If gdb stopped there, the tests verifies gdb is in the kernel
function __kernel_start_sigtramp_rt64 then does an additional stepi to reach the
user signal handler. With the patch below, the tests run without errors on both
the Power 9 and Power 10 systems with out any failures.
|
|
When running test-case gdb.dwarf2/locexpr-data-member-location.exp with
target board unix/-fno-PIE/-no-pie/-m32 I run into:
...
(gdb) step^M
26 return 0;^M
(gdb) FAIL: gdb.dwarf2/locexpr-data-member-location.exp: step into foo
...
The problem is that the test-case tries to mimic some gdb_compile_shlib
behaviour using:
...
set flags {additional_flags=-fpic debug}
get_func_info foo $flags
...
but this doesn't work with the target board setting, because we end up doing:
...
gcc locexpr-data-member-location-lib.c -fpic -g -lm -fno-PIE -no-pie -m32 \
-o func_addr23029.x
...
while gdb_compile_shlib properly filters out the -fno-PIE -no-pie.
Consequently, the address for foo determined by get_func_info doesn't match
the actual address of foo.
Fix this by printing the address of foo using the result of gdb_compile_shlib.
|
|
gdbarch_iterate_over_objfiles_in_search_order callback
A rather straightforward patch to change an instance of callback +
void pointer to gdb::function_view, allowing pasing lambdas that
capture, and eliminating the need for the untyped pointer.
Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
|
|
native-extended-gdbserver board
Running
$ make check TESTS="gdb.gdb/unittest.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
I get some failures:
Running selftest regcache::cooked_write_test::i386.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x64-32.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x64-32:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x86-64.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i386:x86-64:intel.^M
Self test failed: target already pushed^M
Running selftest regcache::cooked_write_test::i8086.^M
Self test failed: target already pushed^M
This is because the native-extended-gdbserver automatically connects GDB
to a GDBserver on startup, and therefore pushes a remote target on the
initial inferior. cooked_write_test is currently written in a way that
errors out if the current inferior has a process_stratum_target pushed.
Rewrite it to use scoped_mock_context, so it doesn't depend on the
current inferior (the current one upon entering the function).
Change-Id: I0357f989eacbdecc4bf88b043754451b476052ad
|
|
My patches yesterday to unify the DWARF index base classes had a bug
-- namely, I did the wholesale dynamic_cast-to-static_cast too hastily
and introduced a crash. This can be seen by trying to add an index to
a file that has an index, or by running a test like gdb-index-cxx.exp
using the cc-with-debug-names.exp target board.
This patch fixes the crash by introducing a new virtual method and
removing some of the static casts.
|
|
For some reason g++ 11.2.1 on s390x produces a spurious warning for
stringop-overread in debuginfod_is_enabled for url_view. Add a new
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD macro to suppress this warning.
include/ChangeLog:
* diagnostics.h (DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD): New
macro.
gdb/ChangeLog:
* debuginfod-support.c (debuginfod_is_enabled): Use
DIAGNOSTIC_IGNORE_STRINGOP_OVERREAD on s390x.
|
|
start_remote_1 calls remote_check_symbols after things are set up to
give the remote side a chance to look up symbols. One call to
remote_check_symbols sets the "general thread", if needed, and sends one
qSymbol packet. However, a remote target could have more than one
process on initial connection, and this would send a qSymbol for only
one of these processes.
Change it to iterate on all the target's inferiors and send a qSymbol
packet for each one.
I tested this by changing gdbserver to spawn two processes on startup:
diff --git a/gdbserver/server.cc b/gdbserver/server.cc
index 33c42714e72..9b682e9f85f 100644
--- a/gdbserver/server.cc
+++ b/gdbserver/server.cc
@@ -3939,6 +3939,7 @@ captured_main (int argc, char *argv[])
/* Wait till we are at first instruction in program. */
target_create_inferior (program_path.get (), program_args);
+ target_create_inferior (program_path.get (), program_args);
/* We are now (hopefully) stopped at the first instruction of
the target process. This assumes that the target process was
Instead of hacking GDBserver, it should also be possible to test this by
starting manually two inferiors on an "extended-remote" connection,
disconnecting from GDBserver (with the disconnect command), and
re-connecting.
I was able to see qSymbol being sent for each inferior:
[remote] Sending packet: $Hgp828dc.828dc#1f
[remote] Packet received: OK
[remote] Sending packet: $qSymbol::#5b
[remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
[remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
[remote] Packet received: qSymbol:6e70746c5f76657273696f6e
[remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
[remote] Packet received: OK
[remote] Sending packet: $Hgp828dd.828dd#21
[remote] Packet received: OK
[remote] Sending packet: $qSymbol::#5b
[remote] Packet received: qSymbol:6764625f6167656e745f6764625f74705f686561705f627566666572
[remote] Sending packet: $qSymbol::6764625f6167656e745f6764625f74705f686561705f627566666572#1e
[remote] Packet received: qSymbol:6e70746c5f76657273696f6e
[remote] Sending packet: $qSymbol::6e70746c5f76657273696f6e#4d
[remote] Packet received: OK
Note that there would probably be more work to be done to fully support
this scenario, more things that need to be done for each discovered
inferior instead of just for one.
Change-Id: I21c4ecf6367391e2e389b560f0b4bd906cf6472f
|
|
Commit 152a17495663 ("gdb: prune inferiors at end of
fetch_inferior_event, fix intermittent failure of
gdb.threads/fork-plus-threads.exp") broke some tests with the
native-gdbserver board, such as:
(gdb) PASS: gdb.base/step-over-syscall.exp: detach-on-fork=off: follow-fork=child: break cond on target : vfork: break marker
continue^M
Continuing.^M
terminate called after throwing an instance of 'gdb_exception_error'^M
I can manually reproduce the issue by running (just the commands that
the test does as a one liner):
$ ./gdb -q --data-directory=data-directory \
testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork \
-ex "tar rem | ../gdbserver/gdbserver - testsuite/outputs/gdb.base/step-over-syscall/step-over-vfork" \
-ex "b main" \
-ex c \
-ex "d 1" \
-ex "set displaced-stepping off" \
-ex "b *0x7ffff7d7ac5a if main == 0" \
-ex "set detach-on-fork off" \
-ex "set follow-fork-mode child" \
-ex c \
-ex "inferior 1" \
-ex "b marker" \
-ex c
... where 0x7ffff7d7ac5a is the exact address of the vfork syscall
(which can be found by looking at gdb.log).
The important part of the above is that a vfork syscall creates inferior
2, then inferior 2 executes until exit, then we switch back to inferior
1 and try to resume it.
The uncaught exception happens here:
#4 0x00005596969d81a9 in error (fmt=0x559692da9e40 "Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.")
at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:43
#5 0x0000559695af6f66 in remote_target::putpkt_binary (this=0x617000038080, buf=0x559692da4380 "qSymbol::", cnt=9) at /home/simark/src/binutils-gdb/gdb/remote.c:9560
#6 0x0000559695af6aaf in remote_target::putpkt (this=0x617000038080, buf=0x559692da4380 "qSymbol::") at /home/simark/src/binutils-gdb/gdb/remote.c:9518
#7 0x0000559695ab50dc in remote_target::remote_check_symbols (this=0x617000038080) at /home/simark/src/binutils-gdb/gdb/remote.c:5141
#8 0x0000559695b3cccf in remote_new_objfile (objfile=0x0) at /home/simark/src/binutils-gdb/gdb/remote.c:14600
#9 0x0000559693bc52a9 in std::__invoke_impl<void, void (*&)(objfile*), objfile*> (__f=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:61
#10 0x0000559693bb2848 in std::__invoke_r<void, void (*&)(objfile*), objfile*> (__fn=@0x61b0000167f8: 0x559695b3cb1d <remote_new_objfile(objfile*)>) at /usr/include/c++/11.2.0/bits/invoke.h:111
#11 0x0000559693b8dddf in std::_Function_handler<void (objfile*), void (*)(objfile*)>::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7ffe0bae0590: 0x0) at /usr/include/c++/11.2.0/bits/std_function.h:291
#12 0x00005596956374b2 in std::function<void (objfile*)>::operator()(objfile*) const (this=0x61b0000167f8, __args#0=0x0) at /usr/include/c++/11.2.0/bits/std_function.h:560
#13 0x0000559695633c64 in gdb::observers::observable<objfile*>::notify (this=0x55969ef5c480 <gdb::observers::new_objfile>, args#0=0x0) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/observable.h:150
#14 0x0000559695df6cc2 in clear_symtab_users (add_flags=...) at /home/simark/src/binutils-gdb/gdb/symfile.c:2873
#15 0x000055969574c263 in program_space::~program_space (this=0x6120000c8a40, __in_chrg=<optimized out>) at /home/simark/src/binutils-gdb/gdb/progspace.c:154
#16 0x0000559694fc086b in delete_inferior (inf=0x61700003bf80) at /home/simark/src/binutils-gdb/gdb/inferior.c:205
#17 0x0000559694fc341f in prune_inferiors () at /home/simark/src/binutils-gdb/gdb/inferior.c:390
#18 0x0000559695017ada in fetch_inferior_event () at /home/simark/src/binutils-gdb/gdb/infrun.c:4293
#19 0x0000559694f629e6 in inferior_event_handler (event_type=INF_REG_EVENT) at /home/simark/src/binutils-gdb/gdb/inf-loop.c:41
#20 0x0000559695b3b0e3 in remote_async_serial_handler (scb=0x6250001ef100, context=0x6170000380a8) at /home/simark/src/binutils-gdb/gdb/remote.c:14466
#21 0x0000559695c59eb7 in run_async_handler_and_reschedule (scb=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:138
#22 0x0000559695c5a42a in fd_event (error=0, context=0x6250001ef100) at /home/simark/src/binutils-gdb/gdb/ser-base.c:189
#23 0x00005596969d9ebf in handle_file_event (file_ptr=0x60700005af40, ready_mask=1) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:574
#24 0x00005596969da7fa in gdb_wait_for_event (block=0) at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:700
#25 0x00005596969d8539 in gdb_do_one_event () at /home/simark/src/binutils-gdb/gdbsupport/event-loop.cc:212
If I enable "set debug infrun" just before the last continue, we see:
(gdb) continue
Continuing.
[infrun] clear_proceed_status_thread: 965604.965604.0
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] scoped_disable_commit_resumed: reason=proceeding
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
[infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=proceeding
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
[infrun] proceed: exit
[infrun] fetch_inferior_event: enter
[infrun] scoped_disable_commit_resumed: reason=handling event
[infrun] do_target_wait: Found 2 inferiors, starting at #1
[infrun] random_pending_event_thread: None found.
[infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) =
[infrun] print_target_wait_results: 965604.965604.0 [Thread 965604.965604],
[infrun] print_target_wait_results: status->kind = VFORK_DONE
[infrun] handle_inferior_event: status->kind = VFORK_DONE
[infrun] context_switch: Switching context from 0.0.0 to 965604.965604.0
[infrun] handle_vfork_done: not waiting for a vfork-done event
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 0
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [965604.965604.0] at 0x7ffff7d7ac5c
[infrun] do_target_resume: resume_ptid=965604.0.0, step=0, sig=GDB_SIGNAL_0
[infrun] prepare_to_wait: prepare_to_wait
[infrun] reset: reason=handling event
[infrun] maybe_set_commit_resumed_all_targets: enabling commit-resumed for target remote
[infrun] maybe_call_commit_resumed_all_targets: calling commit_resumed for target remote
terminate called after throwing an instance of 'gdb_exception_error'
What happens is:
- After doing the "continue" on inferior 1, the remote target gives us
a VFORK_DONE event. The core ignores it and resumes inferior 1.
- Since prune_inferiors is now called after each handled event, in
fetch_inferior_event, it is called after we handled that VFORK_DONE
event and resumed inferior 1.
- Inferior 2 is pruned, which (see backtrace above) causes its program
space to be deleted, which clears the symtabs for that program space,
which calls the new_objfile observable and remote_new_objfile
observer (with a nullptr objfile, to indicate that the previously
loaded symbols have been discarded), which calls
remote_check_symbols.
remote_check_symbols is the function that sends the qSymbol packet, to
let the remote side ask for symbol addresses. The problem is that the
remote target is working in all-stop / sync mode and is currently
resumed. It has sent a vCont packet to resume the target and is waiting
for a stop reply. It can't send any packets in the mean time. That
causes the exception to be thrown.
This wasn't a problem before, when prune_inferiors was called in
normal_stop, because it was always called at a time the target was not
resumed.
An important observation here is that the new_objfile observable is
invoked for a change in inferior 2's program space (inferior 2's program
space is the current program space). Inferior 2 isn't bound to any
process on the remote side (it has exited, that's why it's being
pruned). It doesn't make sense to try to send a qSymbol packet for a
process that doesn't exist on the remote side. remote_check_symbols
actually attempts to avoid that:
/* The remote side has no concept of inferiors that aren't running
yet, it only knows about running processes. If we're connected
but our current inferior is not running, we should not invite the
remote target to request symbol lookups related to its
(unrelated) current process. */
if (!target_has_execution ())
return;
The problem here is that while inferior 2's program space is the current
program space, inferior 1 is the current inferior. So the check above
passes, since inferior has execution. We therefore try to send a
qSymbol packet for inferior 1 in reaction to a change in inferior 2's
program space, that's wrong.
This exposes a conceptual flaw in remote_new_objfile. The "new_objfile"
event concerns a specific program space, which can concern multiple
inferiors, as inferiors can share a program space. We shouldn't
consider the current inferior at all, but instead all inferiors bound to
the affected program space. Especially since the current inferior can
be unrelated to the current program space at that point.
To be clear, we are in this state because ~program_space sets itself as
the current program space, but there is no more inferior having that
program space to switch to, inferior 2 has already been unlinked.
To fix this, make remote_new_objfile iterate on all inferiors bound to
the affected program space. Remove the target_has_execution check from
remote_check_symbols, replace it with an assert. All callers must
ensure that the current inferior has execution before calling it.
Change-Id: Ica643145bcc03115248290fd310cadab8ec8371c
|
|
|
|
|
|
|
|
This permits resolving TLS variables.
|
|
Derive the pointer to the DTV array from the tpidr register.
|
|
|
|
|
|
This permits resolving TLS variables.
|
|
Derive the pointer to the DTV array from the tpidruro register.
|
|
|
|
|
|
FreeBSD's kernel has recently added PT_GETREGSET and PT_SETREGSET
operations to fetch a register set named by an ELF note type. These
helper routines provide helpers to check for a register set's
existence, fetch registers for a register set, and store registers to
a register set.
|
|
When testing gdb.threads/access-mem-running-thread-exit.exp with
--target_board=native-extended-gdbserver, we get:
Running gdb.threads/access-mem-running-thread-exit.exp ...
FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
WARNING: Timed out waiting for EOF in server after monitor exit
=== gdb Summary ===
# of expected passes 3
# of unexpected failures 1
# of unsupported tests 1
The problem is that the testcase spawns a second inferior with
-no-connection, and then runto_main does "run", which fails like so:
(gdb) run
Don't know how to run. Try "help target".
(gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: non-stop: second inferior: runto: run to main
That "run" above failed because native-extended-gdbserver forces "set
auto-connect-native-target off", to prevent testcases from mistakenly
running programs with the native target, which would exactly be the
case here.
Fix this by letting the second inferior share the first inferior's
connection everywhere except on targets that do reload on run (e.g.,
--target_board=native-gdbserver).
Change-Id: Ib57105a238cbc69c57220e71261219fa55d329ed
|
|
While working on this patch:
https://sourceware.org/pipermail/gdb-patches/2022-January/185109.html
I found it really useful to print the executing/resumed status of all
threads (or all threads in a particular inferior) at various
places (e.g. when a new inferior is started, when GDB attaches, etc).
This debug was originally part of the above patch, but I wanted to
rewrite this as a separate patch and move the code into a new function
in infrun.h, which is what this patch does.
Unless 'set debug infrun on' is in effect, then there should be no
user visible changes after this commit.
|
|
It is not necessary to pass an empty string to mi_gdb_start, passing
the empty string is equivalent to passing no arguments, which is what
we do everywhere else (that we don't need to specify an actual
argument).
The only place we use 'mi_gdb_start ""' is in
gdb.mi/mi-break-qualified.exp, so in this commit I just replace that
with a call to 'mi_gdb_start' - just for consistency.
There should be no change in what is tested after this commit.
|
|
After this previous commit I was thinking about the API of
mi_gdb_start. I felt that the idea of passing flags as separate
arguments and using 'args' to gather these into a list, though clever,
was not an intuitive API.
In this commit I modify mi_gdb_start so that it expects a single
argument, which should be a list of flags. Thus, where we previously
would have said:
mi_gdb_start separate-mi-tty separate-inferior-tty
We would now say:
mi_gdb_start { separate-mi-tty separate-inferior-tty }
However, it turns out we never actually call mi_gdb_start passing two
arguments in this way at all. We do in some places do this:
mi_gdb_start separate-inferior-tty
But that's fine, a single string like this works equally well as a
single item list, so this will not need updating.
There is also one place where we do this:
eval mi_gdb_start $start_ops
where $start_ops is a list that might contains 0, 1, or 2 items. The
eval here is used to expand the $start_ops list so mi_gdb_start sees
the list contents as separate arguments. In this case we just need to
drop the use of eval.
I think that the new API is more intuitive, but others might
disagree, in which case I can drop this change.
There should be no change in what is tested after this commit.
|
|
When running with the native-extended-gdbserver board, I currently see
one failure in gdb.mi/mi-exec-run.exp:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
In this test the MI interface should be started in a separate tty,
which means we should have a CLI tty and an MI tty, however, this is
not happening. Instead GDB is just started in MI mode and there is no
CLI tty.
The test script tries to switch between the CLI an MI terminals and
look for some expected output on each, however, as there is no CLI
terminal the expected output never arrives, and the test times out.
It turns out that this is not a GDB problem, rather, this is an issue
with argument passing within the test script.
The proc default_mi_gdb_start expects to take a set of flags (strings)
as arguments, each of flag is expected to be a separate argument. The
default_mi_gdb_start proc collects all its arguments into a list using
the special 'args' parameter name, and then iterates over this list to
see which flags were passed.
In mi_gdb_start, which forwards to default_mi_gdb_start, the arguments
are also gathered into the 'args' parameter list, but are then
expanded back to be separate arguments using the eval trick, i.e.:
proc mi_gdb_start { args } {
return [eval default_mi_gdb_start $args]
}
This ensures that when we arrive in default_mi_gdb_start each flag is
a separate argument, rather than appearing as a single list containing
all arguments.
When using the native-extended-gdbserver board however, the file
boards/native-extended-gdbserver.exp is loaded, and this file replaces
the default mi_gdb_start with its own version.
This new mi_gdb_start also gathers the arguments into an 'args' list,
but forgets to expand the arguments out using the eval trick.
As a result, when using the native-extended-gdbserver board, by the
time we get to default_mi_gdb_start, we end up with the args list
containing a single item, which is a list containing all the arguments
the user passed.
What this means is that if the user passes two arguments, then, in
default_mi_gdb_start, instead of seeing two separate arguments, we see
a single argument made by concatenating the two arguments together.
The only place this is a problem is in the test mi-exec-run.exp,
which (as far as I can see) is the only test where we might try to
pass both arguments at the same time. Currently we think we passed
both arguments to mi_gdb_start, but mi_gdb_start behaves as if no
arguments were passed.
This commit fixes the problem by making use of the eval trick within
the native-extended-gdbserver version of mi_gdb_start. After this,
the FAIL listed at the top of this message is resolved.
|
|
When running the gdb.mi/mi-exec-run.exp test using the
native-extended-gdbserver I see failures like this:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=main: force-fail=1: run failure detected
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=main: mi=separate: force-fail=1: run failure detected
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=1: run failure detected
There's a race condition here, so you might see a slightly different
set of failures, but I always see some from the 'run failure detected'
test.
NOTE: I also see an additional test failure:
FAIL: gdb.mi/mi-exec-run.exp: inferior-tty=separate: mi=separate: force-fail=0: breakpoint hit reported on console (timeout)
but that is a completely different issue, and is not being addressed
in this commit.
The problem for the 'run failure detected' test is that we end up
in gdb_expect looking for output from two spawn-ids, one from
gdbserver, and one from gdb. We're looking for one output pattern
from each spawn-id, and for the test to pass we need to see both
patterns.
Now, if gdb exits then this is a test failure (this would indicate gdb
crashing, which is bad), so we have an eof pattern associated with
the gdb spawn-id.
However, in this particular test we expect gdbserver to fail to
execute the binary (the test binary is set non-executable), and so we
get an error message from gdbserver (which matches the pattern), and
then gdbserver exits, this is expected.
The problem is that after spotting the pattern from gdbserver, we
often see the eof from gdbserver before we see the pattern from gdb.
If this happens then we drop out of the gdb_expect without ever seeing
the pattern from gdb, and fail the test.
In this commit, I place the spawn-id of gdbserver into a global
variable, and then use this global variable as the -i option within
the gdb_expect.
Now, once we have seen the expected pattern on the gdbserver spawn-id,
the global variable is cleared. After this the gdb_expect no longer
checks the gdbserver spawn-id for additional output, and so never sees
the eof event. This leaves the gdb_expect running, which allows the
pattern from gdb to be seen, and for the test to pass.
I now see no failures relating to 'run failure detected'.
|
|
Starting with gcc 12.1 / gcc 11.3, for test-case gdb.cp/align.exp we run into:
...
align.cc:29:23: error: invalid application of 'alignof' to a void type^M
29 | unsigned a_void = alignof (void);^M
| ^~~~~~~~~~~~~~^M
...
Fix this by using __alignof__ instead.
Tested on x86_64-linux, with gcc 7.5.0, gcc 12.1 and clang 12.0.1.
|
|
Currently debuginfod is disabled when the string of server URLs
is unset or set to be the empty string (via the $DEBUGINFOD_URLS
environment variable or the 'set debuginfod urls' gdb command).
Extend this functionality so that a whitespace-only URL also disables
debuginfod.
Modify a testcase to verify that a whitespace-only URL disables
debuginfod.
|
|
The type_wanted value, passed down to the create_sals_from_location
callback, is never used. Remove it.
Change-Id: Ic363ee13f6af593a3e875ff7fe46de130cdc190c
|
|
The breakpoint C++-ification series introduced a regression for Ada
catchpoints. Specifically, commit 2b5ab5b8 ("Convert base breakpoints
to vtable ops") caused these to start failing. I didn't notice this
because testing Ada using a Linux distro compiler requires installing
the GNAT debuginfo, which I hadn't done.
This patch fixes the problem. I'm checking it in.
|
|
When running test-case gdb.multi/attach-no-multi-process.exp with
check-readmore, I get:
...
(gdb) attach 13411^M
Attaching to Remote target^M
No unwaited-for children left.^M
(gdb) Reading symbols from attach-no-multi-process...^M
Reading symbols from /lib64/libm.so.6...^M
(No debugging symbols found in /lib64/libm.so.6)^M
Reading symbols from /lib64/libc.so.6...^M
(No debugging symbols found in /lib64/libc.so.6)^M
Reading symbols from /lib64/ld-linux-x86-64.so.2...^M
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M
0x00007f5df1fffc8a in clock_nanosleep@GLIBC_2.2.5 () from /lib64/libc.so.6^M
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: \
attach to the program via remote (timeout)
...
The problem is that the attach output is matched using gdb_test, which uses
the '$gdb_prompt $' regexp, and this does not handle the case that '(gdb) ' is
not the last available output.
Fix this by using a gdb_test_multiple instead with a '$gdb_prompt ' regexp, so
without the '$' anchor.
Tested on x86_64-linux with native, check-read1 and check-readmore.
|
|
create_breakpoints_sal_default is just a simple wrapper, so remove it.
|
|
allocate_bp_location is just a small wrapper for a method call, so
inline it everywhere.
|
|
Now that all breakpoint_ops are statically initialized, they can all
be made const.
|
|
initialize_breakpoint_ops does not do much any more, so remove it in
favor of statically-initialize objects.
|
|
There's no need to have vtable_breakpoint_ops any more, so remove it
in favor of base_breakpoint_ops.
|
|
At this point, all implementations of breakpoints use the vtable. So,
we can now remove most function pointers from breakpoint_ops and
switch to using methods directly in the callers. Only the two "static
virtual" methods remain in breakpoint_ops.
|
|
init_catchpoint is only ever passed a single breakpoint_ops pointer,
so remove the parameter.
|
