I noticed that "info locals" on a certain large Ada program was very
slow. I tracked this down to ada_get_tsd_type expanding nearly every
CU in the program.
This patch fixes the problem by changing this code to use the more
efficient lookup_transparent_type which, unlike the Ada-specific
lookup functions, does not try to find all matching instances.
Note that I first tried fixing this by changing ada_find_any_type, but
this did not work -- I may revisit this approach at some later date.
Also note that the copyright dates on the test files are set that way
because I copied them from another test.
New in v2: the new test failed on the Linaro regression tester.
Looking at the logs, it seems that gdb was picking up a 'value' from
libgnat:
$1 = {<text variable, no debug info>} 0xf7e227a4 <ada.calendar.formatting.value>
This version renames the local variable in an attempt to work around
this.
v3: In v2, while trying to reproduce the problem locally, I
accidentally forgot to commit one of the changes.
flake8 points out that some code in frame_filters.py is referring to
undefined variables.
In the first hunk, I've changed the code to match what other
'complete' methods do in this file.
In the second hunk, I've simply removed the try/except -- if
get_filter_priority fails, it will raise GdbError, which is already
handled properly by gdb.
The gdb.solib_name() and Progspace.solib_name() functions can throw an
exception if the address argument is not a valid address, but this is
not currently tested.
This commit adds a couple of tests to check that exceptions are thrown
correctly.
An early version of this commit updated the documentation, but it was
pointed out that lots of functions throw an exception if passed an
argument of the wrong type, and we don't document all of these, it's
kind-of assumed that passing an object of the incorrect type might
result in an exception, so this updated version leaves the docs alone,
but I do think adding the extra tests has value.
There's no changes to GDB itself in this commit.
Approved-By: Tom Tromey <tom@tromey.com>
I noticed in passing that the include guard in the file
gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word
DYNAMIC when STATIC would be better, fixed in this commit.
There should be no user visible changes after this commit.
This commit:
commit 6fe4779ac4
Date: Sat Feb 24 11:00:20 2024 +0100
[gdb/build] Fix static cast of virtual base
addressed an issue where GDB would not compile in production mode due
to a use of gdb::checked_static_cast. The problem was that we were
asking GDB to cast from a virtual base class to a sub-class, this
works fine when using dynamic_cast, but does not work with
static_cast.
The gdb::checked_static_cast actually uses dynamic_cast under the hood
in development mode in order to ensure that the cast is valid, while
in a production build we use static_cast as this is more efficient.
What this meant however, was that when gdb::checked_static_cast was
used to cast from a virtual base class, the dynamic_cast of a
non-production build worked fine, while the production build's
static_cast caused a build failure.
However, the gdb::checked_static_cast function already contains some
static_assert calls that are intended to catch any issues with invalid
type casting, the goal of these asserts was to prevent issues like
this: the build only failing in production mode. Clearly the current
asserts are not enough.
I don't think there is a std::is_virtual_base type trait check, so
what I propose instead is that in non-production mode we also make use
of static_cast. This will ensure that any errors that crop up in
production mode should also be revealed in non-production mode, and
should catch issues like this in the future.
There should be no user visible changes after this commit.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399
Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
Support LD_UNDER_TEST environment variable to test a different linker.
Issue an error if LD_UNDER_TEST isn't an absolute full path.
* testsuite/config/default.exp: If LD_UNDER_TEST environment
variable exists, set ld and LD to it and set up tmpdir/ld/ld.
Issue an error if LD_UNDER_TEST isn't an absolute full path.
symtab-> linetable () is set to null in
buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab
has no linetable. Attempting to iterate over this linetable using the
Python API caused GDB to segfault.
Approved-By: Tom Tromey <tom@tromey.com>
In commit 2aaba74446 ("[gdb] Fix "value is not available" with debug frame")
I fixed a case in frame_unwind_register_value where using "set debug frame on"
caused an "info frame" command to abort, reporting a "value is not available"
error, due to the tpidruro register being unavailable.
Subsequently, commit bbb12eb9c8 ("gdb/arm: Remove tpidruro register from
non-FreeBSD target descriptions") removed the unavailable register, which
caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp.
While investigating the progression (see PR python/31437), I found that the
"debug frame" output of the test-case (when reverting commit bbb12eb9c8)
showed a smilar problem:
...
Python Exception <class 'gdb.error'>: value is not available^M
...
that was absent without "debug frame".
Fix this likewise in fetch_lazy_register, and update the test-case to check
for the exception.
Furthermore, I realized that there's both value::entirely_available and
value::entirely_unavailable, and that commit 2aaba74446 handled the case
of !entirely_available by printing unavailable.
Instead, print:
- "unavailable" for entirely_unavailable, and
- "partly unavailable" for !entirely_unavailable && !entirely_available.
Tested on x86_64-linux and arm-linux.
This relaxation is effective for both macro instructions (call36, tail36)
and explicit relocation instructions (pcaddu18i + jirl).
call36 f -> bl f
R_LARCH_CALL36 -> R_LARCH_B26
tail36 $t0, f -> b f
R_LARCH_CALL36 -> R_LARCH_B26
The following instructions are added in this patch:
- ADDPT (predicated): Add checked pointer vectors (predicated).
- ADDPT (unpredicated): Add checked pointer vectors (unpredicated).
- SUBPT (predicated): Subtract checked pointer vectors (predicated).
- SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated).
- MADPT: Multiply-add checked pointer vectors, writing multiplicand
- MLAPT: Multiply-add checked pointer vectors, writing addend
These instructions are part of Checked Pointer Arithmetic extension
and are enabled when both CPA and SVE are enabled. To achieve this,
both flag "+sve" and "+cpa" should be active.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
The following instructions are added in this patch:
- ADDPT and SUBPT - Add/Subtract checked pointer
- MADDPT and MSUBPT - Multiply Add/Subtract checked pointer
These instructions are part of Checked Pointer Arithmetic extension.
This patch adds assembler and disassembler support for these instructions
with relevant checks. Tests are included as well.
A new flag "+cpa" added to documentation. This flag enables CPA extension.
Regression tested on the aarch64-none-linux-gnu target and no regressions
have been found.
ada_bitwise_operation differs from the "usual" bitwise operations only
in that it calls value_cast at the end. However, because gdb is
generally fairly lax about integer types, and because (perhaps oddly)
C-style binary promotion is done here anyway, it seems to me that this
code isn't needed.
ptype is a bit funny, in that it accepts both expressions and type
names. It also evaluates the resulting expression using
EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would
you expect ptype to possibly cause inferior execution?), but is also a
historical artifact of how expressions are implemented (there's no
EVAL_FOR_TYPE).
In Ada, calling a function with an array will sometimes result in a
"thick pointer" array descriptor being made. This is essentially a
structure holding a pointer and bounds information.
Currently, in such a callee, printing the type of the array will yield
funny results:
(gdb) print str.all
$1 = "Hello World"
(gdb) ptype str
type = array (<>) of character
(gdb) ptype str.all
type = array (1 .. 0) of character
That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch
trying to do "something" with an array descriptor, without doing too
much.
I tried briefly to make this code really dereference the array
descriptor and get the correct runtime type. However, that proved to
be tricky; it certainly can't be done for all access types, because
that will cause dynamic type resolution and end up printing just the
runtime type -- which with variants may be pretty far from what the
user may expect.
Instead, this patch arranges to just leave such types alone in this
situation. I don't think this should have an extra effects, because
things like array subscripting still work on thick pointers.
This patch also touches arrayptr.exp, because in that case the access
type is a "thin pointer", and this ensures that the output does not
change in that scenario.
quirk_rust_enum makes string copies to store in an unordered_map.
However, the original strings have an appropriate lifetime, and so no
copying is needed. With C++17, we can rely on string_view having a
std::hash specialization, so this patch changes this code to use
string_view rather than string.
This patch arranges to set __file__ when source'ing a Python script.
This fixes a problem that was introduced by the "source" rewrite, and
then pointed out by Lancelot Six.
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
When certain DAP tests are run in a certain order, dejagnu will throw
an exception during shutdown. After adding many logging statements, I
tracked this down to kill_wait_spawned_process not clearing the
'fileid' board_info entry, causing dejagnu to try to wait for the
process a second time -- and fail.
Tom de Vries then pointed out a second instance of this, which I
tracked down to the same problem occurring when spawning gdbserver.
This version of the patch fixes this by adding a new proc that can be
used to clean up board_info after waiting for a process to exit. I'm
not sure why this problem hasn't affected the test suite in the past.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435
Approved-By: Andrew Burgess <aburgess@redhat.com>
bdfio.c is defining bfd_get_current_time which is returning a time_t.
This type is defined in time.h and thus, must be included in bfd main
header to avoid undefined type when include bfd.h.
Note that most of the time, <time.h> is pulled by <sys/stat.h> already
included in bfd.h. That's why it went unnoticed.
Fedora GDB has carried around a patch for a while which tested
attaching to an i386 process which is stopped within the vDSO library
region. Apparently, at some point in the distant past there was an
issue finding symbol information for this region in this situation.
I'm struggling to track down the precise details of what the original
bug was, however, acquiring symbol information for the vDSO region is
different than for "normal" shared libraries -- the vDSO information
is synthesised within GDB during the attach / inferior creation
process -- so it's not unreasonable to imagine that there could be a
bug specifically in this area of GDB which wouldn't impact "normal"
shared libraries.
I looked for references to vDSO in our testsuite and couldn't find
any tests that looked like they did the same sort of thing, so I'd
like to propose adding this test to our testsuite.
It's a pretty simple test, and doesn't take long to run, so the cost
of adding this is not huge.
Approved-By: Tom Tromey <tom@tromey.com>
Except for bfml{a,s} their 1st and 3rd operands need to match - pass
the TIED macro argument accordingly. While doing that also slightly
re-arrange table entries, such that all predicated insns are close
together.
At the same time change the existing test source to actually use non-
matching operands for the respective bfml{a,s} forms.
Their index is in bits 19, 20, and 22. Bit 11 in particular is already
set in the base opcode. Note also how disassembler output didn't match
assembler input in the respective testcase.
On debian 12, aarch64-linux I run into:
...
(gdb) list .^M
No symbol table is loaded. Use the "file" command.^M
(gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .'
...
The test-case expects some debug info, but none for main. Instead, there's no
debug info at all.
Fix this by adding another source file to the test-case, and compiling it with
debug info.
Tested on aarch64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
PR testsuite/31290
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290
BFD recently changed bfd_mmap to use size_t, not bfd_size_type. This
patch updates gdb_bfd_section_data to follow. Without this patch, if
the two types ever differ, gdb would fail to build.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Irrespective of the encoding being EVEX, the usable SIMD register range
continues to be limited to %xmm0-%xmm15. Enforce this in gas (but
continue to generate code, as in principle we know how to encode
things) and recognize/flag the case in the disassembler.
Oddly enough wrong forms were actually used in the testsuite (register-
only forms are then really meaningless to test here, and are hence
dropped instead of adjusted).
Convert the POP2 test that needs touching anyway (due to a bad ModR/M
byte having been chosen) to .insn.
I tried building gdbserver on postmarketos (which is based on alpine linux,
which uses musl libc), and ran into:
...
gdbserver/linux-low.cc: In lambda function:
gdbserver/linux-low.cc:1907:41: error: \
'W_EXITCODE' was not declared in this scope
1907 | mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true);
| ^~~~~~~~~~
...
The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h.
OTOH, WSETEXIT is defined there, but unused:
...
/* These are not defined in POSIX, but are used by our programs. */
#ifndef WSETEXIT
# ifdef W_EXITCODE
#define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0))
# else
#define WSETEXIT(w,status) ((w) = (0 | ((status) << 8)))
# endif
#endif
...
Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE.
Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make
sure the definition is exercised.
Approved-By: Tom Tromey <tom@tromey.com>
PR build/31483
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483
Make gdbserver's build system locate libiconv when building for Linux.
Commit 07b3255c3b ("Filter invalid encodings from Linux thread names")
make libiconv madantory for building gdbserver on Linux.
While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a
toolchain generated with crosstool-ng), I got:
/home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory
48 | #include <iconv.h>
| ^~~~~~~~~
I downloaded GNU libiconv, built it for that host, and installed it in
an arbitrary directory. I had to modify the gdbserver build system to
locate libiconv and use it, the result is this patch.
I eventually found that crosstool-ng has a config option to make uclibc
provide an implementation of iconv, which is of course much easier. But
given that this patch is now written, I think it would be worth merging
it, it could help some people who do not have iconv built-in their libc
in the future (and may not have the luxury of rebuilding their libc like
I do).
Using AM_ICONV in configure.ac adds these options for configure (the
same we have for gdb):
--with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib
--without-libiconv-prefix don't search for libiconv in includedir and libdir
--with-libiconv-type=TYPE type of library to search for (auto/static/shared)
It sets the `LIBICONV` variable with whatever is needed to link with
libiconv, and adds the necessary `-I` flag to `CPPFLAGS`.
To avoid unnecessarily linking against libiconv on hosts that don't need
it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the
host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`.
Since libiconv is a hard requirement for Linux hosts, error out if it is
not found.
The bits in acinclude.m4 are similar to what we have in
gdb/acinclude.m4.
Update the top-level build system to support building against an in-tree
libiconv (I did not test this part though). Something tells me that the
all-gdbserver dependency on all-libiconv is unnecessary, since there is
already a dependency of configure-gdbserver on all-libiconv (and
all-gdbserver surely depends on configure-gdbserver). I just copied
what's done for GDB though.
ChangeLog:
* Makefile.def: Add configure-gdbserver and all-gdbserver
dependencies on all-libiconv.
* Makefile.in: Re-generate.
Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4
Approved-By: Tom Tromey <tom@tromey.com>
When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can
use the new 'finish_record_with_alignment' method. This lets gdb pass
alignment information to the compiler, which in turn fixes the test
case included in this patch.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397
This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and
GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with
the old gdb try/catch macros, but it no longer is: these should only
ever be called from a 'catch' block, where it's already known that an
exception was thrown.
Simon pointed out, though, that in a few spots, these were in facts
called outside of 'catch' blocks. This patch cleans up these spots.
I also found one spot where a redundant 'return nullptr' could be
removed.
On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into:
...
(gdb) watch data.u.size8twice[1]^M
Hardware watchpoint 241: data.u.size8twice[1]^M
(gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1]
continue^M
Continuing.^M
FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout)
FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write
...
This happens as follows.
We start the exec and set an 8-byte hardware watchpoint on
data.u.size8twice[1] at address 0x440048:
...
(gdb) p sizeof (data.u.size8twice[1])
$1 = 8
(gdb) p &data.u.size8twice[1]
$2 = (uint64_t *) 0x440048 <data+16>
...
We continue execution, and a 16-byte write at address 0x440040 triggers the
hardware watchpoint:
...
4101c8: a9000801 stp x1, x2, [x0]
...
When checking whether a watchpoint has triggered in
aarch64_stopped_data_address, we check against address 0x440040 (passed in
parameter addr_trap). This behaviour is documented:
...
/* ADDR_TRAP reports the first address of the memory range
accessed by the CPU, regardless of what was the memory
range watched. ... */
...
and consequently the matching logic compares against an addr_watch_aligned:
...
&& addr_trap >= addr_watch_aligned
&& addr_trap < addr_watch + len)
...
However, the comparison fails:
...
(gdb) p /x addr_watch_aligned
$3 = 0x440048
(gdb) p addr_trap >= addr_watch_aligned
$4 = false
...
Consequently, aarch64_stopped_data_address returns false, and
stopped_by_watchpoint returns false, and watchpoints_triggered returns 0,
which make infrun think it's looking at a delayed hardware
breakpoint/watchpoint trap:
...
[infrun] handle_signal_stop: stop_pc=0x4101c8
[infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring
...
Infrun then ignores the trap and continues, but runs into the same situation
again and again, causing a hang which then causes the test timeout.
Fix this by allowing a match 8 bytes below addr_watch_aligned. This
introduces the possibility for false positives, so we only do this for regular
"value changed" watchpoints.
An earlier version of this patch worked by aligning addr_watch_aligned to 16
instead of 8:
...
- const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8);
+ const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16);
...
but while that fixed the test-case, it didn't fix the problem completely, so
extend the test-case to check more scenarios.
Tested on aarch64-linux.
Tested-By: Luis Machado <luis.machado@arm.com>
Approved-By: Luis Machado <luis.machado@arm.com>
PR tdep/29423
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423
Change the size type in the BFD mmap interface from bfd_size_type to
size_t to be consistent with the size type of the host mmap interface.
* bfdio.c (bfd_iovec): Change the bmmap size type to size_t.
(bfd_mmap): Likewise.
(memory_bmmap): Likewise.
* cache.c (cache_bmmap): Change the bmmap size type to size_t.
* opncls.c (opncls_bmmap): Change the bmmap size type to size_t.
* bfd-in2.h: Regenerated.
* libbfd.h: Likewise.
Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use
((void *) -1) only if MAP_FAILED is undefined.
* bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for
mmap failure.
* bfdwin.c: Don't include <sys/mman.h>.
(MAP_FILE): Removed.
(bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for
mmap failure.
* cache.c: Don't include <sys/mman.h>.
(cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap
failure.
* opncls.c (opncls_bmmap): Likewise.
* sysdep.h: Include <sys/mman.h> if HAVE_MMAP is define.
(MAP_FILE): New. Defined as 0 if undefined.
(MAP_FAILED): New. Defined as ((void *) -1) if undefined.
