Previous code included the full $srcdir pathnames in the individual
subtest PASS/FAIL names, which makes it difficult to compute
comparisons or regressions between test runs on different machines.
This version switches to the basename only, which are common.
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
Previous code included the full $srcdir pathnames in the individual
subtest PASS/FAIL names, which makes it difficult to compute
comparisons or regressions between test runs on different machines.
This version switches to the basename only, which are common.
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
I noticed that two tests in gdb.ada/complete.exp are testing the same
thing: the completion of "p pck.inne". The second such test has this
comment:
# A fully qualified package name
I believe the intent here was to test "p pck.inner" (note the trailing
"r"). This patch makes this change.
One thing GDB always does when the inferior stops is finding out where
it's stopped at, by way of querying the value of the program counter
register.
To save a packet round trip, the remote target can send the PC
value (often alongside other frequently consulted registers such as the
stack pointer) in the stop reply packet as an "expedited register".
Test that this is actually done for the targets where gdbserver is
supposed to.
Extend the "maintenance print remote-registers" command output with an
"Expedited" column which says "yes" if the register was seen by GDB in
the last stop reply packet it received, and is left blank otherwise.
Tested for regressions on aarch64-linux-gnu native-extended-remote.
The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and
x86_64-linux-gnu native-remote and native-extended-remote targets.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Looks like configure has been generated with a non-upstream autoconf,
re-generate it.
ld/ChangeLog:
* configure: Re-generate.
Change-Id: I6774381ad411a190fb93ff260234dd79d8791680
While reviewing "catch (...)" uses I came across:
...
for (auto &item : local)
{
try
{
item ();
}
catch (...)
{
/* Ignore exceptions in the callback. */
}
}
...
This means that when an item throws a gdb_exception_forced_quit,
the exception is ignored and following items are executed.
Fix this by handling gdb_exception_forced_quit explicity, and immediately
rethrowing it.
I wondered about ^C, and couldn't decide whether current behaviour is ok, so
I left this alone, but I made the issue explicit in the source code.
As for the "catch (...)", I think that it should let a non-gdb_exception
propagate, so I've narrowed it to "catch (const gdb_exception &)".
My rationale for this is as follows.
There seem to be a few ways that "catch (...)" is allowed in gdb:
- clean-up and rethrow (basically the SCOPE_EXIT pattern)
- catch and handle an exception from a call into an external c++ library
Since we're dealing with neither of those here, we remove the "catch (...)".
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
The is patch adds a new ld build-id computation mode, "xx", using
xxhash in its 128-bit mode. The patch prereqs the xxhash-devel
headers being installed, and uses the "all-inlined" model, so no
run-time or link-time library dependence exists.
The xxhash mode performs well, saving roughly 20% of total userspace
run time from an ld job over a 800MB shared library relative to sha1.
128 bits of good hash should be collision-resistant to a number of
distinct binaries that numbers in the 2**32 - 2**64 range, even if not
"crypto" level hash. Confirmations of this are in progress.
ld/configury: add --with-xxhash mode, different from gdb case
because only using it in inline mode
ld/ldbuildid.c: add "xx" mode, #if WITH_XXHASH
ld/NEWS, ld.texi: mention new option
ld/lexsup.c: add enumeration of --build-id STYLES to --help
ld/testsuite/ld-elf/build-id.exp: add test case for 0xHEX case
and conditional for xx case;
also, simply tcl list syntax
https://inbox.sourceware.org/binutils/20240917201509.GB26396@redhat.com/
Signed-off-by: Frank Ch. Eigler <fche@redhat.com>
While reviewing "catch (...)" uses I came across:
...
try
{
fileio_error remote_errno;
m_remote->remote_hostio_close (m_fd, &remote_errno);
}
catch (...)
{
/* Swallow exception before it escapes the dtor. If
something goes wrong, likely the connection is gone,
and there's nothing else that can be done. */
}
...
This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't
know whether these can actually happen here, but if not it's better to
accommodate for the possibility anyway.
Fix this by handling gdb_exception_quit and gdb_exception_forced_quit
explicitly.
It could be that "catch (...)" should be replaced by
"catch (const gdb_exception &)" but that depends on what kind of exception
remote_hostio_close is expected to throw, and I don't know that, so I'm
leaving it as is.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
This is similar to the previous events that we added, and adds support for
SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET.
Though since these are mainly mechanical and not really possible to test,
they are bundled in one commit.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Newer Intel CPUs support recording asynchronous events in the PT trace.
Libipt also recently added support for decoding these.
This patch adds support for interrupt events, based on the existing aux
infrastructure. GDB can now display such events during the record
instruction-history and function-call-history commands.
Subsequent patches will add the rest of the events currently supported.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
Event tracing allows GDB to show information about interesting asynchronous
events when tracing with Intel PT. Subsequent patches will add support for
displaying each type of event.
Enabling event-tracing unconditionally would result in rather noisy output, as
breakpoints themselves result in interrupt events. Which is why this patch adds
a set/show command to allow the user to enable/disable event-tracing before
starting a recording. The event-tracing setting has no effect on an already
active recording. The default setting is off. As event tracing will use the
auxiliary infrastructure added by ptwrite, the user can still disable printing
events, even when event-tracing was enabled, by using the /a switch for the
record instruction-history/function-call-history commands.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
So far we printed "disabled" for gaps, when we saw a ptev_enabled event that
doesn't have the resumed flag set. This is wrong, as the actual disabling
happens with ptev_disabled. So far this didn't matter, but once we have event
tracing, there can be events between a ptev_disabled and a ptev_enabled.
This patch is in preparation for that, and removes the disabled reason in
favour of a more accurate non-contiguous reason, and adjusts the string we
print accordingly.
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
While reviewing "catch (...)" uses I came across:
...
scope_exit (EFP &&f)
try : m_exit_function ((!std::is_lvalue_reference<EFP>::value
&& std::is_nothrow_constructible<EF, EFP>::value)
? std::move (f)
: f)
{
}
catch (...)
{
/* "If the initialization of exit_function throws an exception,
calls f()." */
f ();
}
...
and while looking up the origin of the comment here [1] I saw right after:
...
throws: Nothing, unless the initialization of exit_function throws
...
I think that means that the exception should be rethrown, so fix this by doing
so.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf
In gnu_source_highlight_test we have:
...
try
{
res = try_source_highlight (styled_prog, language_c, fullname);
}
catch (...)
{
saw_exception = true;
}
...
This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't
know whether these can actually happen here, but if not it's better to
accommodate for the possibility anyway.
Fix this by handling gdb_exception explicitly, and rethrowing
gdb_exception_quit and gdb_exception_forced_quit.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC
as used in commit 250f1bbaf3 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with
wrapping disabled"), we can easily reproduce a failure in
gdb.tui/wrap-line.exp mentioned in PR testsuite/31201:
...
(gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678 ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout)
...
The test-case expects wrapping, but that's disabled by horizontal-scroll-mode.
Add a new line to "maint info screen", that describes the current readline
wrapping mode, and use it in the test-case to handle the different cases.
The reported values for the wrapping mode are as follows.
Unsupported because of running in batch mode:
...
$ gdb -q -batch -ex "maint info screen"
Readline wrapping mode: unsupported (gdb batch mode).
...
Unsupported because the terminal is not capable to move the cursor up:
...
$ TERM=dumb gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: unsupported (terminal is not Cursor Up capable).
...
Disabled by horizontal-scroll-mode:
...
$ grep horizontal-scroll-mode ~/.inputrc
set horizontal-scroll-mode on
$ gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: disabled (horizontal-scroll-mode).
...
Wrap done by readline because terminal is not auto wrap capable:
...
$ TERM=ansi gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved).
...
Wrap done by terminal autowrap:
...
$ TERM=xterm gdb -q -ex "maint info screen" -ex q
Readline wrapping mode: terminal (terminal is auto wrap capable).
...
Tested on x86_64-linux.
Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201
Result of:
...
$ search="GDB_PY_SET_HANDLE_EXCEPTION ("
$ replace="return gdbpy_handle_gdb_exception (-1, "
$ sed -i \
"s/$search/$replace/" \
gdb/python/*.c
...
Also remove the now unused GDB_PY_SET_HANDLE_EXCEPTION.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Result of:
...
$ search="GDB_PY_HANDLE_EXCEPTION ("
$ replace="return gdbpy_handle_gdb_exception (nullptr, "
$ sed -i \
"s/$search/$replace/" \
gdb/python/*.c
...
Also remove the now unused GDB_PY_HANDLE_EXCEPTION.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
I've recently committed two patches:
- commit 2f8cd40c37 ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often")
- commit fbf8e4c35c ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often")
which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
more often, with the goal of making things more consistent.
Having done that, I wondered if a better approach could be possible.
Consider GDB_PY_HANDLE_EXCEPTION:
...
/* Use this in a 'catch' block to convert the exception to a Python
exception and return nullptr. */
#define GDB_PY_HANDLE_EXCEPTION(Exception) \
do { \
gdbpy_convert_exception (Exception); \
return nullptr; \
} while (0)
...
The macro nicely codifies how python handles exceptions:
- setting an error condition using some PyErr_Set* variant, and
- returning a value implying that something went wrong
presumably with the goal that using the macro will mean not accidentally:
- forgetting to return on error, or
- returning the wrong value on error.
The problems are that:
- the macro hides control flow, specifically the return statement, and
- the macro hides the return value.
For example, when reading somewhere:
...
catch (const gdb_exception &except)
{
GDB_PY_HANDLE_EXCEPTION (except);
}
...
in order to understand what this does, you have to know that the macro
returns, and that it returns nullptr.
Add a template gdbpy_handle_gdb_exception:
...
template<typename T>
[[nodiscard]] T
gdbpy_handle_gdb_exception (T val, const gdb_exception &e)
{
gdbpy_convert_exception (e);
return val;
}
...
which can be used instead:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception (nullptr, except);
}
...
[ Initially I tried this:
...
template<auto val>
[[nodiscard]] auto
gdbpy_handle_gdb_exception (const gdb_exception &e)
{
gdbpy_convert_exception (e);
return val;
}
...
with which the usage is slightly better looking:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception<nullptr> (except);
}
...
but I ran into trouble with older gcc compilers. ]
While still a single statement, we now have it clear:
- that the statement returns,
- what value the statement returns.
[ FWIW, this could also be handled by say:
...
- GDB_PY_HANDLE_EXCEPTION (except);
+ GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr);
...
but I still didn't find the fact that it returns easy to spot.
Alternatively, this is the simplest form we could use:
...
return gdbpy_convert_exception (e), nullptr;
...
but the pairing would not necessarily survive a copy/paste/edit cycle. ]
Also note how making the value explicit makes it easier to check for
consistency:
...
catch (const gdb_exception &except)
{
return gdbpy_handle_gdb_exception (-1, except);
}
if (PyErr_Occurred ())
return -1;
...
given that we do use the explicit constants almost everywhere else.
Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify
the return value, but I assume that this will be generally copy-pasted and
therefore present no problem.
Also, there's no longer a guarantee that there's an immediate return, but I
assume that nodiscard making sure that the return value is not silently
ignored is sufficient mitigation.
For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION
in terms of gdbpy_handle_gdb_exception.
Follow-up patches will eliminate the macros.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
While looking at PR symtab/31478 (a problem in the cooked indexer with invalid
dwarf) it occurred to me that I could trigger a similar problem using:
...
Compilation Unit @ offset 0xb2:
Length: 0x1f (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xd5>
<1><d4>: Abbrev Number: 0
Compilation Unit @ offset 0xd5:
Length: 0x7 (32-bit)
Version: 4
Abbrev Offset: 0x7f
Pointer Size: 8
...
and indeed I get:
...
$ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2
Fatal signal: Segmentation fault
...
The problem is that we're calling prepare_one_comp_unit with cu == nullptr and
comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists:
...
cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false,
m_index_storage->get_abbrev_cache ());
prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die,
language_minimal);
...
Fix this by bailing out for various types of dummy CUs:
...
if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr
|| !new_reader.comp_unit_die->has_children)
return nullptr;
...
Also make sure in scan_attributes that this triggers a dwarf error:
...
$ gdb -q -batch dw2-inter-cu-error-2
DWARF Error: cannot follow reference to DIE at 0xd5 \
[in module dw2-inter-cu-error-2]
...
With target board readnow, the test-case triggers an assertion failure in
follow_die_offset, so fix this by throwing the same dwarf error.
While we're at it, make the other check for dummy CUs in
cooked_indexer::ensure_cu_exists more robust by adding an intermediate test
for comp_unit_die:
...
- if (result->dummy_p || !result->comp_unit_die->has_children)
+ if (result->dummy_p || result->comp_unit_die == nullptr
+ || !result->comp_unit_die->has_children)
return nullptr;
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
When issuing a command "maint expand-symtabs", maintenance_expand_symtabs is
called with regexp == nullptr, and calls expand_symtabs_matching like so:
...
objfile->expand_symtabs_matching
([&] (const char *filename, bool basenames)
{
/* KISS: Only apply the regexp to the complete file name. */
return (!basenames
&& (regexp == NULL || re_exec (filename)));
},
...
To expand all symtabs gdb usually uses expand_all_symtabs (used for -readnow),
but here we try to handle it in the filename_matcher argument.
Make this more similar to how gdb usually works by using expand_all_symtabs.
A previous version of the patch instead used a nullptr filename_matcher for
the regexp == nullptr case. That approach regressed test-cases
gdb.dwarf2/dwz-unused-pu.exp and gdb.dwarf2/dw2-dummy.exp.
Tested on x86_64-linux.
Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol
from an unused PU is not accessible.
Passes with the relevant target boards:
- unix (using the cooked index),
- readnow (using no index at all),
- cc-with-gdb-index (using .gdb_index), and
- cc-with-debug-names (using .debug_names).
Tested on x86_64-linux.
I noticed when running test-case gdb.ada/info_exc.exp with glibc debug info
installed, that the "info exceptions" command that lists all Ada exceptions
also expands non-Ada CUs, which includes CUs in
/lib64/ld-linux-x86-64.so.2 and /lib64/libc.so.6.
Fix this by:
- adding a new lang_matcher parameter to the expand_symtabs_matching
function, and
- using that new parameter in the expand_symtabs_matching call in
ada_add_global_exceptions.
The new parameter is a hint, meaning implementations are free to ignore it and
expand CUs with any language. This is the case for partial symtabs, I'm not
sure whether it makes sense to implement support for this there.
Conversely, when processing a CU with language C and name "<artificial>"
(as produced by GCC LTO), the CU may not really have a single language and we
should ignore the lang_matcher. See also commit d2f6771173
("Fix 'catch exception' with -flto").
Now that we have lang_matcher available, also use it to limit name splitting
styles and symbol matchers to those applicable to the matched languages.
Without this patch we have (with a gdb build with -O0):
...
$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
real 0m1.866s
user 0m2.089s
sys 0m0.120s
...
and with this patch we have:
...
$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
real 0m0.469s
user 0m0.777s
sys 0m0.051s
...
Or, to put it in terms of number of CUs, we have 1853 CUs:
...
$ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \
-ex start \
-ex "maint info symtabs" \
| grep -c " name "
1853
...
Without this patch, we have:
...
$ gdb -q -batch outputs/gdb.ada/info_exc/foo \
-ex start \
-ex "info exceptions" \
-ex "maint info symtabs" \
| grep -c " name "
1393
...
so ~75% of the CUs is expanded, and with this patch we have:
...
$ gdb <same-as-above>
20
...
so ~1% of the CUs is expanded.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/32182
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182
Some compilers (e.g. the Intel compiler) may dynamically link against
dependencies. The test uses the 'set env' command to set the
LD_LIBRARY_PATH to a test specific value. Update the 'set env' command
to also provide the users LD_LIBARY_PATH to gdb.
Approved-By: Tom Tromey <tom@tromey.com>
The DEBUG_S_INLINEELINES block in the .debug$S section records the line
numbers in a source file covered by inlined functions. It's similar to
the DEBUG_S_LINES block, but as it references LF_FUNC_ID types we also
need to parse it to remap the type numbers.
Since TLS relocation check is ELF specific, enable it only for ELF.
PR gas/32022
* config/tc-i386.c (x86_tls_error_type): Define only if
OBJ_MAYBE_ELF or OBJ_ELF is defined.
(x86_check_tls_relocation): Likewise.
(x86_report_tls_error): Likewise.
(i386_assemble): Check TLS relocations only if OBJ_MAYBE_ELF or
OBJ_ELF is defined.
(md_show_usage): Output -mtls-check= only if OBJ_MAYBE_ELF or
OBJ_ELF is defined.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
I ran the testsuite in an environment simulating a stressed system, and the
only test-cases that timed out in gdb.base were gdb.base/checkpoint.exp and
gdb.base/checkpoint-ns.exp (which includes gdb.base/checkpoints.exp).
In test-case gdb.base/checkpoint.exp there's a part where the timeout is
increased with 120 seconds (in the default case that's from 10 to 130), to
accommodate for a single command creating 600+ checkpoints.
Instead, rewrite the test to present a gdb prompt each time a checkpoint is
created, for which the default timeout is sufficient.
Also ensure that the amount of checkpoints added is exactly 600 rather than
600+.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR python/32163 points out that various types provided by gdb are not
added to the gdb module, so they aren't available for interactive
inspection. I think this is just an oversight.
This patch fixes the problem by introducing a new helper function that
both readies the type and then adds it to the appropriate module. The
patch also poisons PyType_Ready, the idea being to avoid this bug in
the future.
v2:
* Fixed a bug in original patch in gdb.Architecture registration
* Added regression test for the types mentioned in the bug
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
When running the testsuite in an enviroment that simulates a stressed system,
I ran into a timeout in test-case gdb.fortran/info-types.exp:
...
(gdb) info types^M
FAIL: gdb.fortran/info-types.exp: info types (timeout)
...
This is mainly due the presence of glibc debug info.
With it installed, I get:
...
$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
real 0m35.969s
user 0m38.231s
sys 0m1.007s
...
and without:
...
$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
real 0m4.782s
user 0m5.014s
sys 0m0.304s
...
Fix this by not running to main, which gets us:
...
$ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null
real 0m0.808s
user 0m0.789s
sys 0m0.137s
...
Likewise in gdb.mi/mi-sym-info.exp and gdb.mi/mi-complete.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Spotted a comment in code_breakpoint::re_set_default that was added in
commit:
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
that was incorrect. The comment was not updated to take inferior
specific breakpoints into account.
This commit just updates the comment, there's no user visible changes
after this commit.
Even more so than image relative (RVA) relocations, section relative
ones as well as section ones should not have base relocations created in
the final PE image. Reportedly section relative relocations will want
using for TLS support in the (Windows) compiler.
While there also correct the names for two of the "image base" relocs.
The test-case gdb.threads/signal-sigtrap.exp:
- installs a signal handler called sigtrap_handler for SIGTRAP,
- sets a breakpoint on sigtrap_handler, and
- expects the breakpoint to trigger after issuing "signal SIGTRAP".
Usually, that happens indeed:
...
(gdb) signal SIGTRAP^M
Continuing with signal SIGTRAP.^M
^M
Thread 1 "signal-sigtrap" hit Breakpoint 2, sigtrap_handler (sig=5)^M
28 }^M
(gdb) PASS: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
...
Occasionally, I run into this failure on openSUSE Tumbleweed:
...
(gdb) signal SIGTRAP^M
Continuing with signal SIGTRAP.^M
^M
Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M
__pthread_create_2_1 () at pthread_create.c:843^M
(gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
...
AFAIU, the problem is in the situation that is setup before issuing that
command, by running to a breakpoint in thread_function:
...
void *thread_function (void *arg) {
return NULL;
}
int main (void) {
pthread_t child_thread;
signal (SIGTRAP, sigtrap_handler);
pthread_create (&child_thread, NULL, thread_function, NULL);
pthread_join (child_thread, NULL);
return 0;
}
...
In the passing case, thread 2 is stopped in thread_function, and thread 1 is
stopped somewhere in pthread_join:
...
(gdb) info threads^M
Id Target Id Frame ^M
1 Thread ... (LWP ...) "signal-sigtrap" __futex_abstimed_wait_common64 ()
* 2 Thread ... (LWP ...) "signal-sigtrap" thread_function ()
...
In the failing case, thread 2 is stopped in thread_function, but thread 1 is
stopped somewhere in pthread_create:
...
(gdb) info threads^M
Id Target Id Frame ^M
1 Thread ... (LWP ...) "signal-sigtrap" __GI___clone3 ()
* 2 Thread ... (LWP ...) "signal-sigtrap" thread_function ()
...
What I think happens is that pthread_create blocks SIGTRAP at some point, and
if the "signal SIGTRAP" command is issued while that is the case, the signal
becomes pending and consequently there's no longer a guarantee that the signal
will be delivered to the inferior.
Instead the signal will be handled by gdb like this:
...
(gdb) info signals SIGTRAP
Signal Stop Print Pass to program Description
SIGTRAP Yes Yes No Trace/breakpoint trap
...
Fix this by adding a barrier that ensures that pthread_create is done before
we issue the "signal SIGTRAP" command.
Likewise in test-case gdb.threads/signal-command-handle-nopass.exp.
Using the fixed test-case, I tested my theory by explicitly blocking SIGTRAP:
...
+ sigset_t old_ss, new_ss;
+ sigemptyset (&new_ss);
+ sigaddset (&new_ss, SIGTRAP);
+ sigprocmask (SIG_BLOCK, &new_ss, &old_ss);
+
/* Make sure that pthread_create is done once the breakpoint on
thread_function triggers. */
pthread_barrier_wait (&barrier);
pthread_join (child_thread, NULL);
+ sigprocmask (SIG_SETMASK, &old_ss, NULL);
...
and managed to reproduce the same failure:
...
(gdb) signal SIGTRAP^M
Continuing with signal SIGTRAP.^M
[Thread 0x7ffff7c00700 (LWP 13254) exited]^M
^M
Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M
0x00007ffff7c80056 in __GI___sigprocmask () sigprocmask.c:39^M
(gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler
...
Tested on x86_64-linux.
PR testsuite/26867
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26867
After doing pre-commit testing of some patch on arm-linux, the Linaro CI
reported:
...
FAIL: 1 regressions: 1 improvements
regressions.sum:
=== gdb tests ===
Running gdb:gdb.base/return.exp ...
ERROR: no fileid for ccd235fdc9bf
improvements.sum:
=== gdb tests ===
Running gdb:gdb.base/return.exp ...
ERROR: no fileid for 017e9b314c5a
...
The problem is the call to allow_float_test. It calls gdb_exit (for arm-linux
only), and consequently kills the gdb instance setup by prepare_for_testing:
...
if { [prepare_for_testing "failed to prepare" "return"] } {
return -1
}
set allow_float_test [allow_float_test]
...
Fix this by moving the call to allow_float_test to before prepare_for_testing.
Tested on arm-linux and x86_64-linux.
I noticed that introducing a typo here in gdb.mi/mi-breakpoint-changed.exp:
...
set bp_re [mi_make_breakpoint \
- -number $bp_nr \
+ -nunber $bp_nr \
-type dprintf \
-func marker \
-script [string_to_regexp {["printf \"arg\" \""]}]]
...
didn't make the test fail.
Proc mi_make_breakpoint uses parse_args, but does not check the remaining args
as parse_args suggests:
...
proc parse_args { argset } {
parse_list 2 args $argset "-" false
# The remaining args should be checked to see that they match the
# number of items expected to be passed into the procedure
}
...
We could add the missing check in mi_make_breakpoint, but I think the problem
is likely to occur again because the name parse_args does not suggest that
further action is required.
Fix this instead by:
- copying proc parse_args to new proc parse_some_args,
- adding new proc check_no_args_left, and
- calling check_no_args_left in parse_args.
Also be more strict in a few places where we do lassign for remaining args:
...
lassign $args a b
...
There may be more arguments left in $args, so check that that's not the case
using check_no_args_left:
...
set args [lassign $args a b]
check_no_args_left
...
Fix a few test-cases that trigger on the stricter checking.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
PR testsuite/32129
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129
On aarch64-linux (debian testing) with test-case
gdb.base/empty-host-env-vars.exp I ran into:
...
(gdb) show index-cache directory^M
The directory of the index cache is "/home/linux/.cache/gdb".^M
(gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory
...
Without changing any environment variables, the value of the index-cache dir
is:
...
$ gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
and the expectation of the test-case is that setting HOME to empty will
produce an empty dir, but what it actually produces is:
...
$ HOME= gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
There's nothing wrong with that behaviour, the dir is simply constructed using
XDG_CACHE_HOME which happens to be explictly set to its default value
$HOME/.cache [1]:
...
$ echo $XDG_CACHE_HOME
/home/linux/.cache
...
and indeed also setting that variable to empty gets us the expected empty dir:
...
$ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory"
gdb: warning: Couldn't determine a path for the index cache directory.
The directory of the index cache is "".
...
Furthermore, the test-case assumption that setting variables to empty either
produces the original dir or an empty dir is incorrect.
Say that XDG_CACHE_HOME has a non-default value:
...
$ echo $XDG_CACHE_HOME
/home/linux/my-xdg-cache-home
$ gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb".
...
then setting that variable to empty:
...
$ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory"
The directory of the index cache is "/home/linux/.cache/gdb".
...
does change the value of the dir.
Fix this by making the test-case less specific.
While we're at it, factor out regexps re_pre and re_post to make regexps more
readable, and use string_to_regexp to reduce quoting.
Tested on aarch64-linux.
PR testsuite/32132
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132
[1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables
With test-case gdb.base/attach-deleted-exec.exp I ran into:
...
(gdb) attach 121552^M
Attaching to process 121552^M
Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^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/ld64.so.2...^M
(No debugging symbols found in /lib64/ld64.so.2)^M
0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M
(gdb) FAIL: $exp: attach to process with deleted executable
....
The .nfs file indicates:
- that the file has been removed on the NFS server, and
- that the file is still open on the NFS client.
Fix this by detecting this situation, and declaring the test for filename
/proc/PID/exe unsupported.
Tested on:
- x86_64-linux (setup without NFS)
- ppc64le-linux (setup with NFS)
PR testsuite/32130
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130
On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while
I run into (edited for readability):
...
(gdb) ^M
<LOTS-OF-SPACES>-data-evaluate-expression $a^M
-data-evaluate-^done,value="\"FIRST COMMAND\""^M
expression $b(gdb) ^M
^M
^done,value="\"TEST COMPLETE\""^M
(gdb) ^M
PASS: $exp: args=: look for first command output, command length 236
FAIL: $exp: args=: look for second command output, command length 236 (timeout)
...
This is more likely to trigger when running the test-case using
taskset -c <cpu> (where in a big.little setup we pick a little cpu).
The setup here is that the test-case issues these two commands at once:
...
-data-evaluate-expression $a
-data-evaluate-expression $b
...
where the length of the first command is artificially increased by prefixing
it with spaces, show as <LOTS-OF-SPACES> above.
What happens is that gdb, after parsing the first command, executes it.
Then the output of the first command intermixes with the echoing of the second
command, which produces this line containing the first prompt:
...
expression $b(gdb) ^M
...
which doesn't match the \r\n prefix of the regexp supposed to consume the
first prompt:
...
-re "\r\n$mi_gdb_prompt" {
...
Fix this by dropping the \r\n prefix.
Tested on aarch64-linux.
PR testsuite/29781
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781
