gdb: testsuite: Test whether PC register is expedited in gdb.server/server-run.exp
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>
Tom de Vries [Tue, 24 Sep 2024 14:45:27 +0000 (16:45 +0200)]
[gdb] Handle SIGTERM in run_events
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 (...)".
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
Tom de Vries [Tue, 24 Sep 2024 13:17:57 +0000 (15:17 +0200)]
[gdb] Handle ^C in ~scoped_remote_fd
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.
Felix Willgerodt [Tue, 27 Jun 2023 09:20:55 +0000 (11:20 +0200)]
btrace: Add support for further events.
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>
Felix Willgerodt [Mon, 26 Jun 2023 14:54:25 +0000 (16:54 +0200)]
btrace: Add support for interrupt events.
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>
Felix Willgerodt [Wed, 28 Jun 2023 08:15:04 +0000 (10:15 +0200)]
btrace: Enable event tracing on Linux for Intel PT.
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>
Tom de Vries [Tue, 24 Sep 2024 11:47:56 +0000 (13:47 +0200)]
[gdb] Make scope_exit constructor throw
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
Tom de Vries [Tue, 24 Sep 2024 11:41:42 +0000 (13:41 +0200)]
[gdb] Handle ^C in gnu_source_highlight_test
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.
Tom de Vries [Tue, 24 Sep 2024 11:26:15 +0000 (13:26 +0200)]
[gdb/cli] Show readline wrapping mode for maint info screen
With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC
as used in commit 250f1bbaf33 ("[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
Tom de Vries [Tue, 24 Sep 2024 11:06:32 +0000 (13:06 +0200)]
[gdb/python] Add gdbpy_handle_gdb_exception
I've recently committed two patches:
- commit 2f8cd40c37a ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often")
- commit fbf8e4c35c2 ("[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.
Tom de Vries [Tue, 24 Sep 2024 08:50:44 +0000 (10:50 +0200)]
[gdb/symtab] Fix segfault on invalid debug info
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 ());
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;
...
Tom de Vries [Tue, 24 Sep 2024 08:32:41 +0000 (10:32 +0200)]
[gdb/symtab] Use expand_all_symtabs in maint expand-symtabs
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.
Tom de Vries [Tue, 24 Sep 2024 08:32:41 +0000 (10:32 +0200)]
[gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.exp
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).
Tom de Vries [Tue, 24 Sep 2024 08:24:22 +0000 (10:24 +0200)]
[gdb/symtab] Don't expand non-Ada CUs for info exceptions
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 d2f67711730
("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
Rohr, Stephan [Mon, 29 Jan 2024 15:05:40 +0000 (07:05 -0800)]
testsuite, threads: fix LD_LIBRARY_PATH in 'tls-sepdebug.exp'
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.
Mark Harmstone [Tue, 10 Sep 2024 00:21:21 +0000 (01:21 +0100)]
ld/pdb: Handle DEBUG_S_INLINEELINES data
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.
H.J. Lu [Mon, 23 Sep 2024 21:02:22 +0000 (05:02 +0800)]
x86: Enable TLS relocation check only for ELF
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.
Tom de Vries [Mon, 23 Sep 2024 20:03:56 +0000 (22:03 +0200)]
[gdb/testsuite] Avoid large timeout in gdb.base/checkpoint.exp
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+.
Tom Tromey [Wed, 11 Sep 2024 16:35:20 +0000 (10:35 -0600)]
Automatically add types to Python modules
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>
Tom de Vries [Mon, 23 Sep 2024 19:40:16 +0000 (21:40 +0200)]
[gdb/testsuite] Fix timeout in gdb.fortran/info-types.exp
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.
Jan Beulich [Mon, 23 Sep 2024 13:26:29 +0000 (15:26 +0200)]
ld/PE: no base relocs for section (relative) ones
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.
Tom de Vries [Mon, 23 Sep 2024 07:53:54 +0000 (09:53 +0200)]
[gdb/testsuite] Fix failure in gdb.threads/signal-sigtrap.exp
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
...
Tom de Vries [Mon, 23 Sep 2024 07:47:26 +0000 (09:47 +0200)]
[gdb/testsuite] Fix gdb.base/return.exp on arm-linux
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.
Tom de Vries [Mon, 23 Sep 2024 07:34:48 +0000 (09:34 +0200)]
[gdb/testsuite] Make parse_args error out on remaining args
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.
Tom de Vries [Mon, 23 Sep 2024 05:53:20 +0000 (07:53 +0200)]
[gdb/testsuite] Fix gdb.base/attach-deleted-exec.exp with NFS
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)
Tom de Vries [Mon, 23 Sep 2024 05:45:54 +0000 (07:45 +0200)]
[gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp
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" {
...
turned PLT32 relocation against section into PC32 relocation. But these
transformations are valid only for PC-relative relocations. Add fx_pcrel
check for PC-relative relocations when performing these transformations
to keep PLT32 relocation in `movq $foo@PLT, %rax`.
gas/
PR gas/32196
* config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel
for PLT32 relocations.
(i386_validate_fix): Turn PLT32 relocation into PC32 relocation
only if fixp->fx_pcrel is set.
* testsuite/gas/i386/reloc32.d: Updated.
* testsuite/gas/i386/reloc64.d: Likewise.
* testsuite/gas/i386/reloc32.s: Add PR gas/32196 test.
* testsuite/gas/i386/reloc64.s: Likewise.
ld/
PR gas/32196
* testsuite/ld-x86-64/plt3.s: New file.
* testsuite/ld-x86-64/x86-64.exp: Run plt3.
Tom de Vries [Sat, 21 Sep 2024 04:12:40 +0000 (06:12 +0200)]
[gdb/testsuite] Fix timeout in gdb.ada/call_pn.exp
With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into
this timeout:
...
(gdb) maint expand-symtabs^M
FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout)
...
The timeout was related to running the cpu at base frequency of 400Mhz instead
of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core).
But when investigating the test-case I realized that the maint expand-symtabs
could be limited to the source files, so use that to speed up the test-case.
Tested on x86_64-linux.
Co-Authored-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
PR testsuite/32177
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177
Tom de Vries [Sat, 21 Sep 2024 03:55:18 +0000 (05:55 +0200)]
[gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-cases
When running the testsuite in an enviroment simulating a stressed system, I
ran into timeouts in three test-cases in gdb.dwarf2:
- gdb.dwarf2/count.exp,
- gdb.dwarf2/implptrconst.exp, and
- gdb.dwarf2/implptrpiece.exp.
In all three cases, -readnow is used which results in symtabs being expanded for
the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2.
We could address this by limiting the scope of -readnow to the executable, but
after reviewing the test-cases there doesn't seem to be a clear reason to use
-readnow.
Assembler shouldn't accept invalid TLS instructions, TLS relocations
can only be used with specific instructions as specified in TLS psABI
and linker issues an error when TLS relocations are used with wrong
instructions or format. Since it is inconvenient for gcc to rely on
linker to report errors, adding TLS check in the assembler stage so
that gcc can know TLS errors earlier.
gas/ChangeLog:
PR gas/32022
* config.in: Regenerate.
* config/tc-i386.c
*(enum x86_tls_error_type): New.
*(struct _i386_insn): Added has_gotrel to indicate whether TLS
relocations need to be checked.
(x86_check_tls_relocation): Added a new function to check TLS
relocation.
(x86_report_tls_error): Created a new function to report TLS error.
(i386_assemble): Handle x86_check_tls_relocation.
(lex_got): Set i.has_gotrel.
(OPTION_MTLS_CHECK): Added a new option to contrl TLS check.
(struct option): Ditto.
(md_parse_option): Ditto.
(md_show_usage): Ditto.
* configure.ac: Added a new option to check TLS relocation by
default.
* configure: Regenerated.
* doc/c-i386.texi: Document -mtls-check=.
* testsuite/gas/i386/i386.exp: Added new tests.
* testsuite/gas/i386/ilp32/ilp32.exp: Ditto.
* testsuite/gas/i386/ilp32/reloc64.d: Disable TLS check for it.
* testsuite/gas/i386/ilp32/x32-tls.d: Ditto.
* testsuite/gas/i386/inval-tls.l: Added more test cases.
* testsuite/gas/i386/inval-tls.s: Ditto.
* testsuite/gas/i386/reloc32.d: Disable TLS check for it.
* testsuite/gas/i386/reloc64.d: Ditto.
* testsuite/gas/i386/x86-64-inval-tls.l: Added more test cases.
* testsuite/gas/i386/x86-64-inval-tls.s: Ditto.
* testsuite/gas/i386/x86-64.exp: Added new tests.
* testsuite/gas/i386/ilp32/x32-inval-tls.l: New test.
* testsuite/gas/i386/ilp32/x32-inval-tls.s: Ditto.
* testsuite/gas/i386/ilp32/x86-64-tls.d: Ditto.
* testsuite/gas/i386/tls.d: Ditto.
* testsuite/gas/i386/tls.s: Ditto.
* testsuite/gas/i386/x86-64-tls.d: Ditto.
* testsuite/gas/i386/x86-64-tls.s: Ditto.
H.J. Lu [Fri, 20 Sep 2024 19:44:22 +0000 (03:44 +0800)]
ld: Use --no-rosegment to ld for PR ld/22393 tests
The commit
bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map
moves the .note.build-id section before text sections. When --rosegment
and -z separate-code are used together, the .note.gnu.property section
is placed between the .note.build-id section and text sections in the
same PT_LOAD segment by orphan placement. Pass --no-rosegment to ld for
PR ld/22393 tests to avoid linker test failures.
PR ld/32190
* testsuite/ld-elf/pr22393-2a.rd: Pass --no-rosegment to ld.
* testsuite/ld-elf/pr22393-2b.rd: Likewise.
* testsuite/ld-elf/shared.exp: Pass --no-rosegment to ld when
building pr22393-2 tests.
* testsuite/ld-x86-64/pr22393-3a.rd: Pass --no-rosegment to ld.
* testsuite/ld-x86-64/pr22393-3b.rd: Likewise.
* testsuite/ld-x86-64/x86-64.exp: Pass --no-rosegment to ld when
building pr22393-3 tests.
With the previous commits, the only thing entangling elf and coff file
reading with dbx file reading is the functions
{elf|coff}stab_build_psymtabs, defined in dbxread.c. These functions
depend on dbx_symfile_read.
To solve this, I renamed read_stabs_symtab to read_stabs_symtab_1, and
created a function with the original name that does what
dbx_symfile_read used to do.
This way, dbx_symfile_read can just call read_stabs_symtab, and the elf
and coff psymtab builders can also call it directly, fully disentangling
the readers, which would allow us to selectively not compile dbxread in
the future.
gdb: Move read_dbx_symtab to stabsread, and rename to read_stabs_symtab
Despite the name, read_dbx_symtab is not only used for the dbx file
format (also called the aout format). It is used by elf and coff
implicitly as well. So I think it makes more sense to have this function
in the generic stabsread file, so that reading elf files or coff files
depends less on GDB's ability to read dbx files.
There were 11 static functions in dbxread that were onlyl helper
functions, they were moved and kept as static in stabsread.c. Notably,
dbx_read_symtab - which is installed as a callback on legacy_psymtab
for aout, elf and coff at least - has been moved to stabsread.c and
renamed as well; the function that is specific to aout is
dbx_symfile_read, and that hasn't been moved.
Some macros had to be moved as well, but since they are still used
in dbxread, they were moved to the .h file that the struct symloc
is declared, so anyone can properly use the struct.
gdb: Move dbx_end_psymtab to stabsread, and rename to stabs_end_psymtab
This function is used by multiple stabs readers (even if not all), and
the comment in stabsread.h even acknowledges it. I believe that the
comment is incorrect in saying that the function should be in dbxread
because not everyone uses it. If any one reader other than dbx uses
it, the function should be in stabsread, in my opinion.
This commit makes also renames the function to stabs_end_psymtab since,
again, this is not specific to dbx/aout format.
struct symloc had to be moved because stabs_end_psymtab dereferences
symloc objects, so stabsread.c must be aware of the full struct.
The function process_one_symbol was defined in the file dbxread.c, but
this function is used by all file formats that handle stabs debug
information. It makes much more sense for it to be in the stabsread.c
file instead.
To move that function, many other static functions had to be moved from
dbxread. A few were only used by process_one_symbol, so they're still
static, but most were used by other functions still in dbxread, so they
are being exported by stabsread.h
Finally, the registry entry has been moved as well, seeing as it was
already exported by gdb-stabs.h, and stabsread.c will need it to
properly use the newly added function.
With this change, reading mdebug files is totally independent of reading
dbx.
The file dbxread.c, which is responsible for reading stabs information
for multiple file formats, relies heavily on setting and using global
variables over the course of reading symbols.
Future patches aim to make stabs reading more file format independent,
and this patch starts that change by introducing a stabs_context struct,
that will hold all the relevant variables. This context struct is saved
on the registry key inside the objfile being read. Some of those global
variables have been deemed irrelevant:
* dbxread_objfile - Since we're saving in an objfile, this is redundant
* symfile_bfd - It is trivial to get the bfd pointer from the objfile,
so also unnecessary
* string_table_offset - was never initialized, just used to set a value.
That usage was substituted by a hardcoded 0
* next_file_string_table_offset - was only used by read_dbx_symtab, so
it was turned into a local variable there.
As I was moving variables, I also couldn't think of a good reason for
the bincl_list to be a pointer, so it was changed to just be an
std::vector.
gdb/testsuite: rework bp-cond-failure to not depend on inlining
The test gdb.base/bp-cond-failure is implicitly expecting that the
function foo will be inlined twice and gdb will be able to find 2
locations to place a breakpoint. When clang is used, gdb only finds
one location which causes the test to fail. Since the test is not
worried about handling breakpoints on inlined functions, but rather on
the format of the message on a breakpoint condition fail, this seems
like a false fail report.
This commit reworks the test to be in c++, and uses function overloading
to ensure that 2 locations will always be found. Empirical testing
showed that, for clang, we will land on location 2 with the currest exp
commands, no matter the order of the functions declared, whereas for gcc
it depends on the order that functions were declared, so they are
ordered to always land on the second location, this way we are able to
hardcode it and check for it.
Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Tom Tromey <tom@tromey.com>
Nick Clifton [Thu, 19 Sep 2024 15:45:30 +0000 (16:45 +0100)]
ld: Move the .note.build-id section to near the start of the memory map.
This helps GDB to locate the debug information associated with a core dump.
Core dumps include the first page of an executable's image, and if this
page include the .note.build-id section then GDB can find it and then track
down a debug info file for that build-id.
Fixed UBSAN runtime errors such as:
- member call on address which does not point to an object of type 'Vector'
- load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte alignment
gprofng/ChangeLog
2024-09-17 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>.
PR gprofng/32096
* libcollector/unwind.c: Fix UBSAN runtime errors.
* src/CallStack.cc (add_stack_java, add_stack_java_epilogue):
Change argument type to Vector<Histable*>*.
* src/Experiment.cc (update_ts_in_maps): Change variable type.
* src/Experiment.h: Change field type to Vector<Histable*>*.
H.J. Lu [Sun, 15 Sep 2024 23:11:39 +0000 (07:11 +0800)]
x86/APX: Don't promote AVX/AVX2 instructions out of APX spec
V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted
to support EGPR in APX spec. Don't promote them out of APX spec. This
commit effectively reverted:
ec3babb8c10 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed 5a635f1f59a x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} eea4357967b x86/APX: VROUND{P,S}{S,D} can generally be encoded
gdb/testsuite: skip gdb.mi/dw2-ref-missing-frame.exp with clang
The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set
debug information by hand, using a .S file and assembly labels to get
addresses. Unfortunately, clang will always re-arrange the global labels
to be side by side, making high and low PC for CUs and functions be the
same, and thus they will all be empty ranges. This makes the test fail,
since we never technically enter the functions that we want to check.
This commit skips that test when using clang. If we ever port this test
to use the dwarf assembler, we can reenable it with clang.
gdb/testsuite: fix gdb.mi/mi-var-cp.exp with clang
The inline tests in gdb.mi/mi-var-cp.cc were failing when using clang to
run the test. This happened because inline tests want to step past the C
statements and then run the TCL tests, but in mi-var-cp.cc the statement
to be stepped past is "return s2.i;". Since clang links the epilogue
information to the return statement, not the closing brace,
single-stepping past return had us exiting the function - which made the
expressions invalid.
This commit fixes this by making the function have 2 C statements, and
the return one be after all inline tests, so we know GDB won't leave the
function before running the create_varobj tests.
gdb/testsuite: fix gdb.mi/mi-catch-cpp-exceptions.exp with clang
Clang adds line table information for a try/catch block differently to
gcc. Instead of linking the instructions related to __cxa_begin_catch to
the line containing the "catch" statement in the source code, it links
to the closing brace of the try block.
This was causing gdb.mi/mi-catch-cpp-exceptions.exp to fail when tested
with clang. The test was updated to have the catch in the same line as
the closing brace so it passes with no additional modifications with
clang.
MIPS/GAS: Discard redundant instruction from DDIV/DREM macros
A sequence such as:
li at,-1
bne xx,at,0f
li at,1
dsll32 at,at,0x1f
is produced in the expansion of the DDIV and DREM assembly macros, where
a redundant `li at,1' instruction is used to load an intermediate value
of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f'
yielding 0x8000000000000000. However this value likewise results from
left-shifting the value of -1, already present in $at at this point.
Remove the extraneous instruction then, shortening the sequence emitted.
Adjust dumps in the testsuite accordingly.
MIPS/GAS/testsuite: Print instructions in hex in division tests
Add `--show-raw-insn' to division tests so as to verify branch offsets
without the need to know actual offsets into the text section individual
instructions have been assembled at. Add `-z' where applicable to make
interlock NOP instructions appear in output so as to verify them without
the need to know the offsets too. Replace individual offsets to match
against with generic patterns so that a change in the expansion of an
assembly macro does not affect code that follows.
MIPS/opcodes: Rework documentation for instruction args
Rewrite the inline documentation for the characters used in the `args'
member of `struct mips_opcode' to make it consistent in terms of style
and formatting. Discard references to inexistent macros.
Tom de Vries [Sat, 14 Sep 2024 12:09:35 +0000 (14:09 +0200)]
[gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner"
After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
<1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
<120> DW_AT_specification: <0x130>
<2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
<125> DW_AT_name : val1
<12a> DW_AT_const_value : 1
<2><12b>: Abbrev Number: 0
<1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
<12d> DW_AT_name : ns
<2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
<131> DW_AT_name : e
<133> DW_AT_type : <0x118>
<137> DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...
This was reported in PR32160 comment 1.
This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Fix this by reverting the commit.
[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]
That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked. This is to be
addressed in a follow-up patch.
Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix? I've investigated this and filed
PR32160 to track this.
My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.
Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
occur, and
- a DIE that represent the parent scope.
In most cases, these two are the same, but some times they're not.
The debug info above demonstrates such a case. The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.
In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.
So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160
int main () {
return (int)ns::ec::val2;
}
...
compiled with debug info:
...
$ g++ test.c -g
...
When looking at the cooked index entry for val2 using "maint print objfiles",
we get:
...
[7] ((cooked_index_entry *) 0x7f8ecc002ef0)
name: val2
canonical: val2
qualified: ns::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns]
...
which is wrong, there is no source level entity ns::val2.
This is PR symtab/32158.
This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem, and gets us instead:
...
[7] ((cooked_index_entry *) 0x7fba70002ef0)
name: val2
canonical: val2
qualified: ns::ec::val2
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xe9
parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec]
...
Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Tom de Vries [Sat, 14 Sep 2024 12:09:35 +0000 (14:09 +0200)]
[gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900.
Consider the following test-case:
...
$ cat a.h
namespace ns {
class A {
public:
enum {
val1 = 1
};
};
}
$ cat main.c
ns::A a;
int
main (void)
{
return 0;
}
$ cat val1.c
int u1 = ns::A::val1;
...
compiled with debug info:
...
$ g++ main.c val1.c -g
...
When trying to print ns::A::val with current trunk and gdb 15.1 we get:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
There is no field named val1
...
This PR c++/31900.
With gdb 14.2 we get the expected:
...
$ gdb -q -batch a.out -ex "print ns::A::val1"
$1 = ns::A::val1
...
This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Reverting the commit on current trunk fixes the problem.
So how does this problem happen?
First, let's consider the current trunk, with the commit reverted.
Gdb looks for the entry ns::A::val1, and find this entry:
...
[29] ((cooked_index_entry *) 0x7f7830002ef0)
name: val1
canonical: val1
qualified: ns::A::val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0x7f7830002ec0) [A]
...
and expands the corresponding CU val1.c containing this debug info:
...
<2><14a>: Abbrev Number: 3 (DW_TAG_class_type)
<14b> DW_AT_name : A
<14d> DW_AT_byte_size : 1
<3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type)
<151> DW_AT_encoding : 7 (unsigned)
<152> DW_AT_byte_size : 4
<153> DW_AT_type : <0x163>
<159> DW_AT_accessibility: 1 (public)
<4><15a>: Abbrev Number: 5 (DW_TAG_enumerator)
<15b> DW_AT_name : val1
<15f> DW_AT_const_value : 1
<4><160>: Abbrev Number: 0
<3><161>: Abbrev Number: 0
<2><162>: Abbrev Number: 0
...
after which it finds ns::A::val1 in the expanded symtabs.
Now let's consider the current trunk as is (so, with the commit present).
Gdb looks for the entry ns::A::val1, but doesn't find it because the val1
entry is missing its parent:
...
[29] ((cooked_index_entry *) 0x7f5240002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x15a
parent: ((cooked_index_entry *) 0)
...
Then gdb looks for the entry ns::A, and finds this entry:
...
[3] ((cooked_index_entry *) 0x7f5248002ec0)
name: A
canonical: A
qualified: ns::A
DWARF tag: DW_TAG_class_type
flags: 0x0 []
DIE offset: 0xdd
parent: ((cooked_index_entry *) 0x7f5248002e90) [ns]
...
which corresponds to this debug info, which doesn't contain val1
due to -fno-eliminate-unused-debug-types:
...
<2><dd>: Abbrev Number: 3 (DW_TAG_class_type)
<de> DW_AT_name : A
<e0> DW_AT_byte_size : 1
<2><e3>: Abbrev Number: 0
...
Gdb expands the corresponding CU main.c, after which it doesn't find
ns::A::val1 in the expanded symtabs.
The root cause of the problem is the missing parent on the val1
cooked_index_entry, but this only becomes user-visible through the
elaborate scenario above.
Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test
for this problem that doesn't rely on expansion state or
-feliminate-unused-debug-types, but simply tests for the root cause by
grepping for ns::A::val1 in the output of "maint print objfile".
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Tom Tromey [Thu, 12 Sep 2024 23:22:24 +0000 (17:22 -0600)]
Update more types for section index change
Commit f89276a2f3e ("change type of `general_symbol_info::m_section`
to int") did what it says in the title -- changed the type of the
section index from short to int. However, it seems incomplete, in
that there are uses of the section index that use the type 'short'.
This patch fixes the ones I found, first by searching for
"short.*sect" and then by looking at all the callers of section_index
(and then functions called with the resulting value) just to try to be
more sure.
Approved-by: Kevin Buettner <kevinb@redhat.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Tue, 10 Sep 2024 17:05:04 +0000 (11:05 -0600)]
Fix quoting in gdb-add-index.sh
When the filename quoting change was merged into the AdaCore tree, we
saw a regression in a test setup that uses the DWARF 5 index (that is
running gdb-add-index), and a filename with a space in it.
Initially I thought this was a change in the 'file' command -- but
looking again, I found out that 'file' has worked this way for a
while, and our immediate error was caused by the (documented) change
to "save gdb-index".
While I'm not sure why this test was working previously, it seems to
me that gdb-add-index.sh requires a change to quote the arguments to
"file" and "save gdb-index".
While working on this, though, it seemed to me that multiple other
spots needed quoting for the script to work correctly. And, I was
unable to get quoting working correctly in the objcopy calls, so I
split it into multiple different invocations.
Tom Tromey [Wed, 11 Sep 2024 15:25:45 +0000 (09:25 -0600)]
Add quoting to 'file' invocations in DAP
Oleg Tolmatcev noticed that DAP launch and attach requests don't
properly handle Windows filenames, because "file" doesn't handle the
backslash characters correctly. This patch adds quoting to the
command in an attempt to fix this.
Simon Marchi [Mon, 12 Aug 2024 17:09:05 +0000 (13:09 -0400)]
gdb/solib: use owning_intrusive_list for solib list
Functions implementing `solib_ops::current_sos` return a list of solib
object, transferring the ownership to their callers. However, the
return type, `intrusive_list<solib>`, does not reflect that.
Also, some of these functions build these lists incrementally, reading
this from the target for each solib. If a target read were to throw,
for instance, the already created solibs would just be leaked.
Change `solib_ops::current_sos` to return an owning_intrusive_list to
address that. Change `program_space::so_list` to be an
owning_intrusive_list as well. This also saves us doing a few manual
deletes.
Change-Id: I6e4071d49744874491625075136c59cce8e608d4 Reviewed-by: Keith Seitz <keiths@redhat.com>
It occured to me that `intrusive_list<solib>`, as returned by
`solib_ops::current_sos`, for instance, is not very safe. The
current_sos method returns the ownership of the solib objects
(heap-allocated) to its caller, but the `intrusive_list<solib>` type
does not convey it. If a function is building an
`intrusive_list<solib>` and something throws, the solibs won't
automatically be deleted. Introduce owning_intrusive_list to fill this
gap.
Interface
---------
The interface of owning_intrusive_list is mostly equivalent to
intrusive_list, with the following differences:
- When destroyed, owning_intrusive_list deletes all element objects.
The clear method does so as well.
- The erase method destroys the removed object.
- The push_front, push_back and insert methods accept a `unique_ptr<T>`
(compared to `T &` for intrusive_list), taking ownership of the
object.
- owning_intrusive_list has emplace_front, emplace_back and emplace
methods, allowing to allocate and construct an object directly in the
list. This is really just a shorthand over std::make_unique and
insert (or push_back / push_front if you don't care about the return
value), but I think it is nicer to read:
These methods are not `noexcept`, since the allocation or the
constructor could throw.
- owning_intrusive_list has a release method, allowing to remove an
element without destroying it. The release method returns a
pair-like struct with an iterator to the next element in the list
(like the erase method) and a unique pointer transferring the
ownership of the released element to the caller.
- owning_intrusive_list does not have a clear_and_dispose method, since
that is typically used to manually free items.
Implementation
--------------
owning_intrusive_list privately inherits from intrusive_list, in order
to re-use the linked list machinery. It adds ownership semantics around
it.
Testing
-------
Because of the subtle differences in the behavior in behavior and what
we want to test for each type of intrusive list, I didn't see how to
share the tests for the two implementations. I chose to copy the
intrusive_list tests and adjust them for owning_intrusive_list.
The verify_items function was made common though, and it tries to
dereference the items in the list, to make sure they have not been
deleted by mistake (which would be caught by Valgrind / ASan).
Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760 Co-Authored-By: Pedro Alves <pedro@palves.net> Reviewed-by: Keith Seitz <keiths@redhat.com>
Simon Marchi [Mon, 12 Aug 2024 17:09:03 +0000 (13:09 -0400)]
gdbsupport/intrusive-list: make insert return an iterator
Make the insert method return an iterator to the inserted element. This
mimics what boost does [1] and what the standard library insert methods
generally do [2].
Simon Marchi [Mon, 12 Aug 2024 17:09:02 +0000 (13:09 -0400)]
gdbsupport/intrusive-list: sprinkle noexcept
Some methods of intrusive_list are marked noexcept. But really,
everything in that file could be noexcept. Add it everywhere.
The only one I had a doubt about is clear_and_dispose: what if the
disposer throws? The boost equivalent [1] is noexcept and requires the
disposer not to throw. The rationale is probably the same as for
destructors. What if the disposer throws for an element in the middle
of the list? Do you skip the remaining elements? Do you swallow the
exception and keep calling the disposer for the remaining elements?
It's simpler to say no exceptions allowed.
Stephan Rohr [Wed, 21 Feb 2024 09:55:37 +0000 (01:55 -0800)]
testsuite, trace: add guards if In-Process Agent library is not found
Several tests in gdb.trace trigger TCL errors if the In-Process Agent
library is not found, e.g.:
Running gdb/testsuite/gdb.trace/change-loc.exp ...
ERROR: tcl error sourcing gdb/testsuite/gdb.trace/change-loc.exp.
ERROR: error copying "gdb/gdb/testsuite/../../gdbserver/libinproctrace.so":
no such file or directory
while executing
"file copy -force $fromfile $tofile"
(procedure "gdb_remote_download" line 29)
invoked from within
"gdb_remote_download target $target_file"
(procedure "gdb_download_shlib" line 6)
invoked from within
"gdb_download_shlib $file"
(procedure "gdb_load_shlib" line 2)
invoked from within
"gdb_load_shlib $libipa"
(file "gdb/testsuite/gdb.trace/change-loc.exp" line 354)
invoked from within
"source gdb/testsuite/gdb.trace/change-loc.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source gdb/testsuite/gdb.trace/change-loc.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Protect against this error by checking if the library is available.
Simon Marchi [Thu, 12 Sep 2024 12:27:08 +0000 (08:27 -0400)]
gdb: change type of `general_symbol_info::m_section` to int
The binary provided with bug 32165 [1] has 36139 ELF sections. GDB
crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1:
$ ./gdb -nx -q --data-directory=data-directory ./vmlinux
Reading symbols from ./vmlinux...
(No debugging symbols found in ./vmlinux)
(gdb) info func
/usr/include/c++/14.2.1/debug/vector:508:
In function:
std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp,
_Allocator>::operator[](size_type) [with _Tp = long unsigned int;
_Allocator = std::allocator<long unsigned int>; reference = long
unsigned int&; size_type = long unsigned int]
Error: attempt to subscript container with out-of-bounds index -29445, but
container only holds 36110 elements.
Objects involved in the operation:
sequence "this" @ 0x514000007340 {
type = std::debug::vector<unsigned long, std::allocator<unsigned long> >;
}
The crash occurs here:
#3 0x00007ffff5e334c3 in __GI_abort () at abort.c:79
#4 0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320
#5 0x0000555561119a16 in std::__debug::vector<unsigned long, std::allocator<unsigned long> >::operator[] (this=0x514000007340, __n=18446744073709522171)
at /usr/include/c++/14.2.1/debug/vector:508
#6 0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517
#7 0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value])
at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983
#8 0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189
#9 0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1)
at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361
#10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525
That is, at this line of `minimal_symbol::value_address`, where
`objfile->section_offsets` is an `std::vector`:
But going up one frame, the section index is 36091:
(top-gdb) frame
#1 0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false,
address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228
1228 msymbol->set_section_index (section);
It seems like the problem is just that the type used for the section
index (short) is not big enough. Change from short to int. If somebody
insists, we could even go long long / int64_t, but I doubt it's
necessary.
This leverages commit ("s390: Simplify (dis)assembly of insn operands
with const bits") to relax the operand constraints of the immediate
operand that contains the constant Z- or T-bit of the following extended
mnemonics:
risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt
Previously those instructions were the only ones where the assembler
on s390 restricted the specification of the subject I3/I4 operand values
exactly according to their specification to an unsigned 6- or 5-bit
unsigned integer. For any other instructions the assembler allows to
specify any operand value allowed by the instruction format, regardless
of whether the instruction specification is more restrictive.
Allow to specify the subject I3/I4 operand as unsigned 8-bit integer
with the constant operand bits being ORed during assembly.
Relax the instructions subject significant operand bit masks to only
consider the Z/T-bit as significant, so that the instructions get
disassembled as their *z or *t flavor regardless of whether any reserved
bits are set in addition to the Z/T-bit.
Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set
the T-bit in operand I3, as they otherwise get disassembled as their
rnsbgt, rosbgt, and rxsbgt counterpart.
This aligns GNU Assembler to LLVM Assembler.
opcodes/
* s390-opc.c (U6_18, U5_27, U6_26): Remove.
(INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define
as INSTR_RIE_RRUUU while retaining insn fmt mask.
(MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only
Z/T-bit of I3/I4 operand as significant.
gas/testsuite/
* gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit.
s390: Simplify (dis)assembly of insn operands with const bits
Simplify assembly and disassembly of extended mnemonics with operands
with constant ORed bits:
Their instruction template already contains the respective constant
operand bits, as they are significant to distinguish the extended from
their base mnemonic. Operands are ORed into the instruction template.
Therefore it is not necessary to OR the constant bits into the operand
value during assembly in s390_insert_operand.
Additionally the constant operand bits from the instruction template
can be used to mask them from the operand value during disassembly in
s390_print_insn_with_opcode. For now do so for non-length unsigned
integer operands only.
The separate instruction formats need to be retained, as their masks
differ, which is relevant during disassembly to distinguish the base
and extended mnemonics from each other.
projects / thirdparty / binutils-gdb.git / log
