| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This method returns type units too, so "get_unit" is a better name.
Change-Id: I6ec9de3f783637a3e206bcaaec96a4e00b4b7d31
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Makes it possible to set and remove other types of breakpoints while the
process is running. Makes debugging more convenient.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
During testing csr instructions in risc-v, it occurs that instruction csrrci
is unsupported for recording process and there is such warning:
'warning: Currently this instruction with len 4(100174f3) is unsupported', so
recording failed. This patch fixes this error.
|
|
|
|
With MSYS2 and test-case gdb.ada/assign_1.exp, we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) \
[answered Y; input not from terminal]^M^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
GDB automatically answers the query, because interactive-mode is off:
...
(gdb) show interactive-mode^M
Debugger's interactive mode is auto (currently off).^M^M
...
The correct value is on, because GDB was started in a terminal.
For some reason, the auto value of interactive-mode is off instead. According
to this patch [1], gdb doesn't recognize the pipes used by DejaGnu testsuite
as an interactive setup.
Fix this by adding "set interactive-mode on" to INTERNAL_GDBFLAGS, such that
we get:
...
(gdb) dir^M
Reinitialize source path to empty? (y or n) y^M
Source directories searched: $cdir;$cwd^M^M
(gdb)
...
and no longer need fixes like commit be740e7cc62 ("testsuite: skip
confirmation in 'gdb_reinitialize_dir'")
The fix is essentially the same as in aforementioned patch.
For consistency, we apply the fix for all platforms.
Co-Authored-By: Pierre Muller <muller@sourceware.org>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html
|
|
With MSYS2 and default TERM=xterm-256color (as well as with xterm and ansi), I
get:
...
builtin_spawn gdb -q ...
^[[6n(gdb) ERROR: GDB never initialized.
...
This is not specific to gdb, other tools produce the same CSI sequence, and
consequently we run into trouble in other places (like get_compiler_info).
Fix this by default-setting TERM to dumb.
We do this for all platforms, to avoid test-cases passing on one platform but
failing on another.
For test-cases that set TERM to something other than dumb, handle the CSI
sequence in default_gdb_start.
Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/33072
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33072
|
|
Recent GDB commits added more features related to linker namespaces and
documented them on the manual, but did not add a convenient way for a
user to understand what they are. This commit adds a quick explanation
of what they are.
It also fixes the inconsistency of using "linker namespaces" and
"linkage namespaces", by always using the first form to avoid user
confusion.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Remove comma from: gdb.flush([, stream]) . I suspect this was a copy
and paste from gdb.write(string [, stream]) where the comma is
correct.
|
|
amd_dbgapi_target_breakpoint::check_status
ROCgdb handles target events very slowly when running a test case like
this, where a breakpoint is preset on HipTest::vectorADD:
for (int i=0; i < numDevices; ++i) {
HIPCHECK(hipSetDevice(i));
hipLaunchKernelGGL(HipTest::vectorADD, dim3(blocks), dim3(threadsPerBlock), 0, stream[i],
static_cast<const int*>(A_d[i]), static_cast<const int*>(B_d[i]), C_d[i], N);
}
What happens is:
- A kernel is launched
- The internal runtime breakpoint is hit during the second
hipLaunchKernelGGL call, which causes
amd_dbgapi_target_breakpoint::check_status to be called
- Meanwhile, all waves of the kernel hit the breakpoint on vectorADD
- amd_dbgapi_target_breakpoint::check_status calls process_event_queue,
which pulls the thousand of breakpoint hit events from the kernel
- As part of handling the breakpoint hit events, we write the PC of the
waves that stopped to decrement it. Because the forward progress
requirement is not disabled, this causes a suspend/resume of the
queue each time, which is time-consuming.
The stack trace where this all happens is:
#32 0x00007ffff6b9abda in amd_dbgapi_write_register (wave_id=..., register_id=..., offset=0, value_size=8, value=0x7fffea9fdcc0) at /home/smarchi/src/amd-dbgapi/src/register.cpp:587
#33 0x00005555588c0bed in amd_dbgapi_target::store_registers (this=0x55555c7b1d20 <the_amd_dbgapi_target>, regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2504
#34 0x000055555a5186a1 in target_store_registers (regcache=0x507000002240, regno=470) at /home/smarchi/src/wt/amd/gdb/target.c:3973
#35 0x0000555559fab831 in regcache::raw_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:890
#36 0x0000555559fabd2b in regcache::cooked_write (this=0x507000002240, regnum=470, src=...) at /home/smarchi/src/wt/amd/gdb/regcache.c:915
#37 0x0000555559fc3ca5 in regcache::cooked_write<unsigned long, void> (this=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:850
#38 0x0000555559fab09a in regcache_cooked_write_unsigned (regcache=0x507000002240, regnum=470, val=140737323456768) at /home/smarchi/src/wt/amd/gdb/regcache.c:858
#39 0x0000555559fb0678 in regcache_write_pc (regcache=0x507000002240, pc=0x7ffff62bd900) at /home/smarchi/src/wt/amd/gdb/regcache.c:1460
#40 0x00005555588bb37d in process_one_event (event_id=..., event_kind=AMD_DBGAPI_EVENT_KIND_WAVE_STOP) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1873
#41 0x00005555588bbf7b in process_event_queue (process_id=..., until_event_kind=AMD_DBGAPI_EVENT_KIND_BREAKPOINT_RESUME) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:2006
#42 0x00005555588b1aca in amd_dbgapi_target_breakpoint::check_status (this=0x511000140900, bs=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:890
#43 0x0000555558c50080 in bpstat_stop_status (aspace=0x5070000061b0, bp_addr=0x7fffed0b9ab0, thread=0x518000026c80, ws=..., stop_chain=0x50600014ed00) at /home/smarchi/src/wt/amd/gdb/breakpoint.c:6126
#44 0x000055555984f4ff in handle_signal_stop (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:7169
#45 0x000055555984b889 in handle_inferior_event (ecs=0x7fffeaa40ef0) at /home/smarchi/src/wt/amd/gdb/infrun.c:6621
#46 0x000055555983eab6 in fetch_inferior_event () at /home/smarchi/src/wt/amd/gdb/infrun.c:4750
#47 0x00005555597caa5f in inferior_event_handler (event_type=INF_REG_EVENT) at /home/smarchi/src/wt/amd/gdb/inf-loop.c:42
#48 0x00005555588b838e in handle_target_event (client_data=0x0) at /home/smarchi/src/wt/amd/gdb/amd-dbgapi-target.c:1513
Fix that performance problem by disabling the forward progress
requirement in amd_dbgapi_target_breakpoint::check_status, before
calling process_event_queue, so that we can process all events
efficiently.
Since the same performance problem could theoritically happen any time
process_event_queue is called with forward progress requirement enabled,
add an assert to ensure that forward progress requirement is disabled
when process_event_queue is invoked. This makes it necessary to add a
require_forward_progress call to amd_dbgapi_finalize_core_attach. It
looks a bit strange, since core files don't have execution, but it
doesn't hurt.
Add a test that replicates this scenario. The test launches a kernel
that hits a breakpoint (with an always false condition) repeatedly.
Meanwhile, the host process loads an unloads a code object, causing
check_status to be called.
Bug: SWDEV-482511
Change-Id: Ida86340d679e6bd8462712953458c07ba3fd49ec
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
inferior
A following patch will want to call require_forward_progress for a given
inferior. Extract a new require_forward_progress overload from the
existing require_forward_progress function that targets a specific
inferior.
Change-Id: I54f42b83eb8443d4d91747ffbc86eaeb017f1e49
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
Pass the amd_dbgapi_inferior_info object from process_event_queue to
process_one_event. Since process_event_queue pulls events for one
specific inferior, we know for which inferior the event is. This
removes the need for process_one_event to do two dbgapi calls to get the
relevant pid. If also removes one inferior lookup.
Change-Id: I22927e4b6251513eb3be95785082058aa3d09954
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
A following patch will make process_event_queue access a field of
amd_dbgapi_inferior_info. Prepare for this by making
process_event_queue accept an amd_dbgapi_inferior_info object, instead
of a process id.
Change-Id: I9adc491dd1ff64ff74c40aa7662fffb11bd8332b
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
I didn't have a problem in this area, but it seems to me that this
pre-condition should always hold. We should only disable forward
progress requirement if the target says it's ok to do so. Otherwise, we
could get in a situation where we wait for events from amd-dbgapi, which
will never arrive, because amd-dbgapi didn't actually resume things.
Change-Id: Ifc49f55c7874924b7c47888b8391a07a01d960fc
Approved-by: Lancelot Six <lancelot.six@amd.com>
|
|
Rely on the default value.
Change-Id: I08c683de005806c5c5d29ed7f9b0c6de81b49a01
Approved-By: Lancelot Six <lancelot.six@amd.com>
|
|
When running test-case gdb.python/py-source-styling-2.exp with TERM=dumb, I
get:
...
(gdb) set style enabled on^M
warning: The current terminal doesn't support styling. \
Styled output might not appear as expected.^M
(gdb) FAIL: $exp: set style enabled on
...
Fix this by using with_ansi_styling_terminal on clean_restart.
Tested on x86_64-linux.
|
|
The manual section on using GDB under Emacs is out-of-date and
duplicates existing and comprehensive documentation in the Emacs
manual.
Replace the section by a short introduction and reference.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
This value will likely never change at runtime, so we might as well make
it a template parameter. This has the "advantage" of being able to
remove the unnecessary param from gdb::sequential_for_each.
Change-Id: Ia172ab8e08964e30d4e3378a95ccfa782abce674
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I find this file difficult to work with and modify, due to how it uses
the preprocessor to include itself, to generate variations of the test
functions. Change it to something a bit more C++-y, with a test
function that accepts a callback to invoke the foreach function under
test.
Change-Id: Ibf1e2907380a88a4f8e4b4b88df2b0dfd0e9b6c8
|
|
Change-Id: Iaac252aa2abbe169153e79b84f956cda172c69d1
|
|
I noticed a minor grammer issue in a comment in DAP.
|
|
Setting a BP on a line like this would incorrectly yield two BP locations:
01 void two () { {int var = 0;} }
(gdb) break 1
Breakpoint 1 at 0x1164: main.cpp:1. (2 locations)
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000001164 in two() at main.cpp:1
1.2 y 0x0000000000001164 in two() at main.cpp:1
In this case decode_digits_ordinary () returns two SALs, exactly matching the
requested line. One for the entry PC and one for the prologue end PC. This
was
tested with GCC, CLANG and ICPX. Subsequent code tries to skip the prologue
on these PCs, which in turn makes them the same.
To fix this, ignore SALs with the same PC and program space when adding to the
list of SALs.
This will then properly set only one location:
(gdb) break 1
Breakpoint 1 at 0x1164: file main.cpp, line 1
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y 0x0000000000001164 in two() at main.cpp:1
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Convert 'set debug linux-namespaces' to the new(er) debug scheme. As
part of this change I converted the mnsh_debug_print_message function,
which previously printed its output, to instead return a std::string,
this string is then printed using linux_namespaces_debug_printf. The
mnsh_debug_print_message function is only used as part of the debug
output.
I also updated one place in the code where debug_linux_namespaces, the
debug control variable, which is a boolean, was assigned an integer.
When debug is turned on then clearly the output is now different, but
in all other cases, there should be no user visible change in GDB
after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The tables in z80-tdep.c previously either gave these instructions the
wrong size, or failed to recognize them by using the wrong masks, or
both. The fixed instructions alongside their representation in octal are:
* add ii,rr: [0335] 00r1 (where r & 1 == 1)
[0375] 00r1
* ld (ii+d,n): [0335] 0066 <d> <n>
[0375] 0066 <d> <n>
Prefix bytes inside [] do not count towards instruction length in
these tables.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33066
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Remove period from subsubsection titles in the AArch64 configuration-specific
subsection, and expand acronyms.
Regarding @cindex entries, remove periods and standardise their order
and the position of "AArch64" to make it easier to find them by
using the index-searching commands of Info readers that offer TAB
completion.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
The Windows port does not support multi-process debugging. Testcases
that want to exercise multi-process currently FAIL and some hit
cascading timeouts. Add a new allow_multi_inferior_tests procedure,
meant to be used with require, and sprinkle it throughout testcases as
needed.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I4a10d8f04f9fa10f4b751f140ad0a6d31fbd9dfb
|
|
Cygwin debugging does not support follow fork. There is currently no
interface between the debugger and the Cygwin runtime to be able to
intercept forks and execs. Consequently, testcases that try to
exercise fork/exec all FAIL, and several hit long cascading timeouts.
Add a new allow_fork_tests procedure, meant to be used with require,
and sprinkle it throughout testcases that exercise fork.
Note that some tests currently are skipped on targets other than
Linux, with something like:
# Until "set follow-fork-mode" and "catch vfork" are implemented on
# other targets...
#
if {![istarget "*-linux*"]} {
continue
}
However, some BSD ports also support fork debugging nowadays, and the
testcases were never adjusted... That is why the new allow_fork_tests
procedure doesn't look for linux.
With this patch, on Cygwin, I get this:
$ make check TESTS="*/*fork*.exp"
...
=== gdb Summary ===
# of expected passes 6
# of untested testcases 1
# of unsupported tests 31
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: I0c5e8c574d1f61b28d370c22a0b0b6bc3efaf978
|
|
Running gdb.multi/attach-no-multi-process.exp on Cygwin, where
GDBserver does not support non-stop mode, I see:
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=off: info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Let's ignore the first "info threads" fail. The timeouts look like
this:
builtin_spawn /home/alves/gdb-cache-cygwin/gdb/../gdbserver/gdbserver --once --multi localhost:2346
Listening on port 2346
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) gdb_do_cache: can_spawn_for_attach ( )
builtin_spawn /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.multi/attach-no-multi-process/attach-no-multi-process
attach 14540
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: attach to the program via remote (timeout)
info threads
FAIL: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: info threads (timeout)
Note the "Non-stop mode requested, but remote does not support
non-stop" line.
The intro to gdb_target_cmd_ext says:
# gdb_target_cmd_ext
# Send gdb the "target" command. Returns 0 on success, 1 on failure, 2 on
# unsupported.
That's perfect here, we can just use gdb_target_cmd_ext instead of
gdb_target_cmd, and check for 2 (unsupported). That's what this patch
does.
However gdb_target_cmd_ext incorrectly returns 1 instead of 2 for the
case where the remote target says it does not support non-stop. That
is also fixed by this patch.
With this, we no longer get those timeout fails. We get instead:
target extended-remote localhost:2346
Remote debugging using localhost:2346
Non-stop mode requested, but remote does not support non-stop
(gdb) UNSUPPORTED: gdb.multi/attach-no-multi-process.exp: target_non_stop=on: non-stop RSP
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I1ab3162f74200c6c02a17a0600b102d2d12db236
|
|
On Cygwin, starting an inferior under GDB, and detaching it, quitting
GDB, and then closing the shell, like so:
(gdb) start
(gdb) detach
(gdb) quit
# close shell
... hangs the parent shell of GDB (not GDB!) until the inferior
process that was detached (as it is still using the same terminal GDB
was using) exits too.
This leads to odd failures in gdb.base/watchpoint-hw-attach.exp like
so:
detach
Detaching from program: .../outputs/gdb.base/watchpoint-hw-attach/watchpoint-hw-attach, process 16580
[Inferior 1 (process 16580) detached]
(gdb) FAIL: gdb.base/watchpoint-hw-attach.exp: detach
Fix this by converting the testcase to spawn the inferior outside GDB,
with spawn_wait_for_attach.
With this patch, the testcase passes cleanly on Cygwin, for me.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8e3884073a510d6fd2fff611e1d26fc808adc4fa
|
|
Commit 58984e4a ("Use gdb::function_view in iterate_over_threads")
broke the Solaris build. This patch attempts to fix it, changing
find_signalled_thread to have the correct signature, and correcting a
couple of problems in sol_thread_target::get_ada_task_ptid.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33073
|
|
When writing commit 28f15782adab ("gdb/dwarf: read multiple .debug_info.dwo
sections"), I initially thought that the gcc behavior of producing multiple
.debug_info.dwo sections was a bug (it is not). I updated the commit
message, but it looks like this comment stayed. Remove it, since it can
be misleading.
Change-Id: I027712d44b778e836f41afbfafab993da02726ef
Approved-By: Tom Tromey <tom@tromey.com>
|
|
While C++ifying the solib code, I concluded that all arches that use
SVR4 libraries do provide link map offsets, so I think this function is
unnecessary now.
Change-Id: Ifaae2560d92f658df3724def6219e2f89054e4b7
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Running gdb.cp/cpexprs.exp on x86-64 GNU/Linux, I see:
break base::~base
Breakpoint 117 at 0x555555555d90: file .../src/gdb/testsuite/gdb.cp/cpexprs.cc, line 135.
(gdb) continue
Continuing.
Breakpoint 117, base::~base (this=0x7fffffffd0f8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) PASS: gdb.cp/cpexprs.exp: continue to base::~base
Here, the breakpoint only got one location because both the in-charge
and the not-in-charge dtors are identical and got the same address:
$ nm -A ./testsuite/outputs/gdb.cp/cpexprs/cpexprs| c++filt |grep "~base"
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
./testsuite/outputs/gdb.cp/cpexprs/cpexprs:0000000000001d84 W base::~base()
While on Cygwin, we get two locations for the same breakpoint, which
the testcase isn't expecting:
break base::~base
Breakpoint 117 at 0x100402678: base::~base. (2 locations)
(gdb) continue
Continuing.
Thread 1 "cpexprs" hit Breakpoint 117.1, base::~base (this=0x7ffffcaf8, __in_chrg=<optimized out>) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:135
135 ~base (void) { } // base::~base
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to base::~base
We got two locations because the in-charge and the not-in-charge dtors
have different addresses:
$ nm -A outputs/gdb.cp/cpexprs/cpexprs.exe | c++filt | grep "~base"
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402680 T base::~base()
outputs/gdb.cp/cpexprs/cpexprs.exe:0000000100402690 T base::~base()
On Cygwin, we also see the typical failure due to not expecting the
inferior to be multi-threaded:
(gdb) continue
Continuing.
[New Thread 628.0xe08]
Thread 1 "cpexprs" hit Breakpoint 200, test_function (argc=1, argv=0x7ffffcc20) at .../src/gdb/testsuite/gdb.cp/cpexprs.cc:336
336 derived d;
(gdb) FAIL: gdb.cp/cpexprs.exp: continue to test_function for policyd3::~policyd
Both issues are fixed by this patch, and now the testcase passes
cleanly on Cygwin, for me.
Reviewed-By: Keith Seitz <keiths@redhat.com>
Change-Id: If7eb95d595f083f36dfebf9045c0fc40ef5c5df1
|
|
I noticed on Cygwin, gdb.thread/thread-execl.exp would hang, (not that
surprising since we can't follow-exec on Cygwin). Looking at the
process list running on the machine, we end up with a thread-execl.exe
process constantly respawning another process [1].
We see the same constant-reexec if we launch gdb.thread/thread-execl
manually on the shell:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
# * doesn't exit, constantly re-execing *
^C
Prevent this leftover constantly-re-execing scenario by making the
testcase program only exec once. We now get:
$ ./testsuite/outputs/gdb.threads/thread-execl/thread-execl
$ # exits immediately after one exec.
On Cygwin, the testcase now fails reasonably quickly, and doesn't
leave stale processes behind.
Still passes cleanly on x86-64 GNU/Linux.
[1] Cygwin's exec emulation spawns a new Windows process for the new
image.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Change-Id: I0de1136cf2ef7e89465189bc43489a2139a80efb
|
|
Cygwin supports dumping ELF cores via a dumper.exe utility, see
https://www.cygwin.com/cygwin-ug-net/dumper.html.
When I run a testcase that has the "kernel" generate a corefile, like
gdb.base/corefile.exp, Cygwin invokes dumper.exe correctly and
generates an ELF core file, however, the testsuite doesn't find the
generated core:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/corefile.exp ...
WARNING: can't generate a core file - core tests suppressed - check ulimit -c
The file is correctly put under $coredir, e.g., like so:
outputs/gdb.base/corefile/coredir.8926/corefile.exe.core
The problem is in this line in core_find:
foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {
Note that that isn't looking for "${binfile}.core" inside
${coredir}... That is fixed in this patch.
However, that still isn't sufficient for Cygwin + dumper, as in that
case the core is going to be called foo.exe.core, not foo.core. Fix
that by looking for foo.exe.core in the core dir as well.
With this, gdb.base/corefile.exp and other tests that use core_find
now run. They don't pass cleanly, but at least now they're exercised.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ic807dd2d7f22c5df291360a18c1d4fbbbb9b993e
|
|
The gdb.base/sigall.exp testcase has many FAILs on Cygwin currently.
From:
Thread 1 "sigall" received signal SIGPWR, Power fail/restart.
0x00007ffeac9ed134 in ntdll!ZwWaitForSingleObject () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) FAIL: gdb.base/sigall.exp: get signal LOST
we see two issues. The test is expecting "Program received ..." which
only appears if the inferior is single-threaded. All Cygwin inferiors
are multi-threaded, because both Windows and the Cygwin runtime spawn
a few helper threads.
And then, SIGLOST is the same as SIGPWR on Cygwin. The testcase
already knows to treat them the same on SPARC64 GNU/Linux. We just
need to extend the relevant code to treat Cygwin the same.
With this, the test passes cleanly on Cygwin.
Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: Ie3553d043f4aeafafc011347b6cb61ed58501667
|
|
The gdb.arch/amd64-watchpoint-downgrade.exp testcase is assuming the
output of debugging a single-thread program, like so, on e.g.,
GNU/Linux:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
warning: watchpoint 1 downgraded to software watchpoint
Program stopped.
0x00007ffff7fe32b0 in _start () from /lib64/ld-linux-x86-64.so.2
However, on Cygwin, where all inferiors are multi-threaded (because
both Windows and the Cygwin runtime spawn a few helper threads), we
get:
starti
Starting program: .../gdb.arch/amd64-watchpoint-downgrade/amd64-watchpoint-downgrade
[New Thread 4652.0x17e4]
warning: watchpoint 1 downgraded to software watchpoint
Thread 1 stopped.
0x00007ffbfc1c0911 in ntdll!LdrInitShimEngineDynamic () from C:/Windows/SYSTEM32/ntdll.dll
This commit adjusts the testcase to work with either output.
(Note GDB may print a thread name after the thread number.)
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I3aedfec04924ea3fb3bb87ba3251e2b720f8d59c
|
|
On Cygwin, all inferiors are multi-threaded, because both Windows and
the Cygwin runtime spawn a few helper threads. Adjust the
gdb.base/bp-permanent.exp testcase to work with either single- or
multi-threaded inferiors.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I28935b34fc9f739c2a5490e83aa4995d29927be2
|
|
Currently on Cygwin, I get:
Running /home/alves/gdb/src/gdb/testsuite/gdb.base/bp-cond-failure.exp ...
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=short: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=int: cond_eval=auto: single-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: multi-loc: continue
FAIL: gdb.base/bp-cond-failure.exp: access_type=long long: cond_eval=auto: single-loc: continue
On GNU/Linux, we see:
Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) PASS: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
While on Cygwin, we see:
Thread 1 "bp-cond-failure" hit Breakpoint 2.1, foo () at .../src/gdb/testsuite/gdb.base/bp-cond-failure.c:21
21 return 0; /* Multi-location breakpoint here. */
(gdb) FAIL: gdb.base/bp-cond-failure.exp: access_type=char: cond_eval=auto: multi-loc: continue
The difference is the "Thread 1" part in the beginning of the quoted
output. It appears on Cygwin, but not on Linux. That's because on
Cygwin, all inferiors are multi-threaded, because both Windows and the
Cygwin runtime spawn a few helper threads.
Fix this by adjusting the gdb.base/bp-cond-failure.exp testcase to
work with either single- or multi-threaded inferiors.
The testcase passes cleanly for me after this.
Approved-by: Kevin Buettner <kevinb@redhat.com>
Change-Id: I5ff11d06ac1748d044cef025f1e78b8f84ad3349
|
|
When building on x86_64-cygwin, I run into:
...
In file included from gdbsupport/common-defs.h:203,
from gdb/defs.h:26,
from <command-line>:
gdb/ser-unix.c: In function ‘void hardwire_setbaudrate(serial*, int)’:
gdbsupport/gdb_locale.h:28:20: error: expected ‘)’ before ‘gettext’
28 | # define _(String) gettext (String)
| ^~~~~~~
gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
| ^
gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^~~~~~~~~~~~~~~~~~~~~~
gdb/ser-unix.c:590:31: note: in expansion of macro ‘_’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^
gdbsupport/gdb_locale.h:28:28: note: to match this ‘(’
28 | # define _(String) gettext (String)
| ^
gdbsupport/gdb_assert.h:43:43: note: in expansion of macro ‘_’
43 | internal_error_loc (__FILE__, __LINE__, _("%s: " message), __func__, \
| ^
gdb/ser-unix.c:590:7: note: in expansion of macro ‘gdb_assert_not_reached’
590 | gdb_assert_not_reached (_("Serial baud rate was not found in B_codes"));
| ^~~~~~~~~~~~~~~~~~~~~~
...
Fix this by dropping the unneeded _() on the gdb_assert_not_reached argument.
PR build/33064
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33064
|
|
On s390x-linux, with test-case gdb.ada/dyn-bit-offset.exp and gcc 7.5.0 I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -6, another_field => -6)^M
(gdb) FAIL: $exp: print spr
print spr.field^M
$2 = -6^M
(gdb) FAIL: $exp: print spr.field
...
On x86_64-linux, with the same compiler version I get:
...
(gdb) print spr^M
$1 = (discr => 3, array_field => (-5, -6, -7), field => -4, another_field => -4)^M
(gdb) XFAIL: $exp: print spr
print spr.field^M
$2 = -4^M
(gdb) PASS: $exp: print spr.field
...
In both cases, we're hitting the same compiler problem, but it manifests
differently on little and big endian.
Make sure the values seen for both little and big endian trigger xfails
for both tests.
Printing spr.field gives the expected value -4 for x86_64, but that's an
accident. Change the actual spr.field value to -5, to make sure
that we get the same number of xfails on x86_64 and s390x.
Finally, make the xfails conditional on the compiler version.
Tested using gcc 7.5.0 on both x86_64-linux and s390x-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/33042
https://sourceware.org/bugzilla/show_bug.cgi?id=33042
|
|
For reference see the previous commit.
Fix a memory leak in gdbscm_parse_command_name when a guile exception
is thrown. To reveal the memory leak I placed the following content
into a file 'leak.scm':
(use-modules (gdb))
(register-command!
(make-command
"break cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
Then in GDB:
(gdb) source leak.scm
ERROR: In procedure register-command!:
In procedure gdbscm_register_command_x: Out of range: 'break' is not a prefix command in position 1: "break cmd"
Error while executing Scheme code.
Running this under valgrind reveals a memory leak for 'result' and
'prefix_text' from gdbscm_parse_command_name.
Another leak can be revealed with this input script:
(use-modules (gdb))
(register-command!
(make-command
"unknown-prefix cmd"
#:command-class COMMAND_OBSCURE
#:invoke (lambda (self arg from-tty)
(display "Hello World"))))
This one occurs earlier in gdbscm_parse_command_name, and now only
'result' leaks.
The problem is that, when guile throws an exception then a longjmp is
performed from the function that raise the exception back to the guile
run-time. A consequence of this is that no function local destructors
will be run.
In gdbscm_parse_command_name, this means that the two function locals
`result` and `prefix_text` will not have their destructors run, and
any memory managed by these objects will be leaked.
Fix this by assigning nullptr to these two function locals before
throwing an exception. This will cause the managed memory to be
deallocated.
I could have implemented a fix that made use of Guile's dynwind
mechanism to register a cleanup callback, however, this felt like
overkill. At the point the exception is being thrown we know that we
no longer need the managed memory, so we might as well just free the
memory at that point.
With this fix in place, the two leaks are now fixed in the valgrind
output.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
In gdbpy_parse_command_name (python/py-cmd.c) there is a call to
xmalloc that can easily be replaced with a call to
make_unique_xstrndup, which makes the code easier to read (I think).
In gdbscm_parse_command_name (guile/scm-cmd.c) the same fix can be
applied to remove an identical xmalloc call. And there is an
additional xmalloc call, which can also be replaced with
make_unique_xstrndup in the same way.
The second xmalloc call in gdbscm_parse_command_name was also present
in gdbpy_parse_command_name at one point, but was replaced with a use
of std::string by this commit:
commit 075c55e0cc0a68eeab777027213c2f545618e844
Date: Wed Dec 26 11:05:57 2018 -0700
Remove more calls to xfree from Python
I haven't changed the gdbscm_parse_command_name to use std::string
though, as that doesn't work well with the guile exception model.
Guile exceptions work by performing a longjmp from the function that
raises the exception, back to the guile run-time. The consequence of
this is that destructors are not run. For example, if
gdbscm_parse_command_name calls gdbscm_out_of_range_error, then any
function local objects in gdbscm_parse_command_name will not have
their destructors called.
What this means is that, for the existing `result` and `prefix_text`
locals, any allocated memory managed by these objects will be leaked
if an exception is called. However, fixing this is pretty easy, one
way is to just assign nullptr to these locals before raising the
exception, this would cause the allocated memory to be released.
But for std::string it is harder to ensure that the managed memory has
actually been released. We can call std::string::clear() and then
maybe std::string::shrink_to_fit(), but this is still not guaranteed
to release any managed memory. In fact, I believe the only way to
ensure all managed memory is released, is to call the std::string
destructor.
And so, for functions that can throw a guile exception, it is easier
to just avoid std::string.
As for the memory leak that I identify above; I'll fix that in a
follow on commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When the convenience variable $_linker_namespace was introduced, I meant
for it to print the namespace of the frame that where the user was
stopped. However, due to confusing what "current_frame" and
"selected_frame" meant, it instead printed the namespace of the
lowermost frame.
This commit updates the code to follow my original intent. Since the
variable was never in a GDB release, updating the behavior should not
cause any disruption. It also adds a test to verify the functionality.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Modern unix systems allow to set custom baud rate instead of predefined in termios.h.
- To use this in Linux it must have BOTHER macro in "asm/termio.h"
- MacOS could handle this using IOSSIOSPEED passed to ioctl()
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I5bc95982f5d90c7030b73f484ecc0f75c060ebf7
|
|
Added B_codes that may be supported in some unix systems
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I48624d6573dc6c72e26818dd44b24182c1dabb70
|
|
Replace a manual xfree with unique_xmalloc_ptr.
Change-Id: Id4d2065e3294c4761fe3c852962360712b53d7a8
Approved-By: Tom Tromey <tom@tromey.com>
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
|
|
Replace a manual xfree with unique_xmalloc_ptr.
Change-Id: I12a20106545905f1a80d069fc0555812cc3d6680
Approved-By: Tom Tromey <tom@tromey.com>
Approved-by: Lancelot Six <lancelot.six@amd.com> (amdgpu)
|
|
Internal AdaCore testing using -gdwarf-4 found a spot where GCC will
emit a negative DW_AT_bit_offset. However, my recent signed/unsigned
changes assumed that this value had to be positive.
I feel this bug somewhat invalidates my previous thinking about how
DWARF attributes should be handled.
In particular, both GCC and LLVM at understand that a negative bit
offset can be generated -- but for positive offsets they might use a
smaller "data" form, which is expected not to be sign-extended. LLVM
has similar code but GCC does:
if (bit_offset < 0)
add_AT_int (die, DW_AT_bit_offset, bit_offset);
else
add_AT_unsigned (die, DW_AT_bit_offset, (unsigned HOST_WIDE_INT) bit_offset);
What this means is that this attribute is "signed but default
unsigned".
To fix this, I've added a new attribute::confused_constant method.
This should be used when a constant value might be signed, but where
narrow forms (e.g., DW_FORM_data1) should *not* cause sign extension.
I examined the GCC and LLVM DWARF writers to come up with the list of
attributes where this applies, namely DW_AT_bit_offset,
DW_AT_const_value and DW_AT_data_member_location (GCC only, but LLVM
always emits it as unsigned, so we're safe here).
This patch corrects the bug and imports the relevant test case.
Regression tested on x86-64 Fedora 41.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32680
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Turns out that using 'set debug breakpoint on' will trigger an
assertion for 'catch' style breakpoints, e.g.:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) catch exec
Catchpoint 1 (exec)
(gdb) set debug breakpoint on
(gdb) start
[breakpoint] dump_condition_tokens: Tokens: { INFERIOR: "1" }
Temporary breakpoint 2 at 0x401198: file /tmp/hello.c, line 18.
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
Starting program: /tmp/hello.x
[breakpoint] update_global_location_list: insert_mode = UGLL_MAY_INSERT
../../gdb-16.1/gdb/gdbarch-gen.c:1764: internal-error: gdbarch_addr_bit: Assertion `gdbarch != NULL' failed.
.... etc ...
The problem is that catch breakpoints don't set the
bp_location::gdbarch member variable, they a "dummy" location added
with a call to add_dummy_location (breakpoint.c).
The breakpoint_location_address_str function (which is only used for
breakpoint debug output) relies on bp_location::gdbarch being set in
order to call the paddress function.
I considered trying to ensure that the bp_location::gdbarch variable
is always set to sane value. For example, in add_dummy_location I
tried copying the gdbarch from the breakpoint object, and this does
work for the catchpoint case, but for some of the watchpoint cases,
even the breakpoint object has no gdbarch value set.
Now this seemed a little suspect, but, the more I thought about it, I
wondered if "fixing" the gdbarch was allowing me to solve the wrong
problem.
If the gdbarch was set, then this would allow us to print the address
field of the bp_location, which is going to be 0, after all, as this
is a dummy location, which has no address.
But does it really make sense to print the address 0? For some
targets, 0 is a valid address. But that wasn't an address we actually
selected, it's just the default value for dummy locations.
And we already have a helper function bl_address_is_meaningful, which
returns false for dummy locations.
So, I propose that in breakpoint_location_address_str, we use
bl_address_is_meaningful to detect dummy locations, and skip the
address printing code in that case.
For testing, I temporarily changed insert_bp_location so that
breakpoint_location_address_str was always called, even when
breakpoint debugging was off. I then ran the whole testsuite.
Without the fixes included in this commit I saw lots of assertion
failures, but with the fixes from this commit in place, I now see no
assertion failures.
I've added a new test which reveals the original assertion failure.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
My recent GDB commit:
commit 4b42385c470c5f72f158f382f4d9c36f927aa84f
Author: Guinevere Larsen <guinevere@redhat.com>
Date: Wed Feb 12 08:25:46 2025 -0300
gdb: Make dwarf support optional at compile time
Introduced a change that made the configure script not POSIX compliant,
by using fallthrough in some case statements. This commit reworks that
part of the change to only use if statements, so that no code is
duplicated but things remain POSIX compliant.
Reviewed-by: Sam James <sam@gentoo.org>
Approved-By: Tom Tromey <tom@tromey.com>
|
