I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix some by using gdb_test_lines, as well as related gdb_get_lines.
Tested on x86_64-linux.
This adds some per-BFD locking to gdb_bfd_map_section and
gdb_bfd_get_full_section_contents.
It turned out that the background DWARF reader could race with the
auto-load code, because the reader might try to mmap a section when
the main thread was trying to read in .debug_gdb_scripts.
The current BFD threading model is that only BFD globals will be
locked, so any multi-threaded use of a BFD has to be handled specially
by the application.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
This changes auto-load.c ot use gdb_bfd_get_full_section_contents.
This shouldn't change any behavior, but makes it easier to add locking
in a subsequent patch.
Reviewed-by: Kevin Buettner <kevinb@redhat.com>
A few tests on the testsuite require dwarf5 to work. Up until now, the
way to do this was to explicitly add the command line flag -gdwarf-5.
This isn't very portable, in case a compiler requires a different flag
to emit dwarf5.
This commit adds a new option to gdb_compile that would be able to add
the correct flag (if known) or error out in case we are unable to tell
which flag to use. It also changes the existing tests to use this
general option instead of hard coding -gdwarf-5.
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
This patch started as an attempt to allow the 'Size attribute to be
applied to types, and not just objects.
However, that turns out to be difficult due to the Ada semantcs of
'Size. In particular, Ada requires 'Size to denote the size of the
representation of the value, so for example Boolean'Size must be 1.
Implementing this properly requires information not readily available
to gdb... and while we could synthesize this information in many
cases, it also seemed to me that this wasn't strictly very useful when
debugging.
So instead, this patch adds support for the 'Object_Size attribute,
which is somewhat closer to 'sizeof'.
Note also that while 'Object_Size is defined for some dynamic types, I
chose not to implement this here, as again this information is not
readily available -- and I think it's preferable to error than to
print something that might be incorrect.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I ran the testsuite with a patch setting dwarf_synchronous to false by
default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp
and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did
not show up as a result of the file command.
Fix this by forcing "maint set dwarf synchronous on".
Add the same in gdb.base/index-cache.exp, where this is also required.
Tested on aarch64-linux.
I ran into:
...
(gdb) pipe maint print objfiles self-spec | grep c1^M
name: c1^M
canonical: c1^M
qualified: c1^M
[3] ((addrmap *) 0xfffedfc1f010)^M
(gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index
...
Fix this by renaming the class from c1 to class1.
Tested on aarch64-linux.
When building gdb with -O2 -fsanitize=thread and running test-case
gdb.base/bg-exec-sigint-bp-cond.exp, I run into:
...
(gdb) c&^M
Continuing.^M
(gdb) Quit^M
(gdb) quit_count=1
^M
Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M
23 return 0;^M
FAIL: $exp: no force memory write: \
SIGINT does not interrupt background execution
...
What happens is that:
- the breakpoint hits
- while evaluating the condition of the breakpoint,
$_shell("kill -INT <pid-of-gdb>") is called, handled by run_under_shell
- in run_under_shell, a vfork is issued
- in the vfork child, execl executes the kill command
- in the vfork parent, waitpid is called to wait for the result of the kill
command
- waitpid returns -1 with errno set to EINTR
- run_under_shell doesn't check the result of waitpid, and returns the
value of local variable status. Since waitpid returned -1, status was
not assigned a value, so it's uninitialized, and happens to be
non-zero
- the breakpoint condition evaluates to true, because
$_shell("kill -INT <pid-of-gdb>") != 0
- the breakpoint triggers a stop, which the test-case doesn't expect.
Fix this by using gdb::handle_eintr to call waitpid in run_under_shell.
Also handle the case that waitpid returns an error other than EINTR, using
perror_with_name.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR gdb/30695
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695
With target board unix we get:
...
$ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \
-ex "info function operator\*"
All functions matching regular expression "operator\*":
File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
but with target board cc-with-dwz-m:
...
All functions matching regular expression "operator\*":
File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h:
72: void foo::operator*(foo&);
85: void foo::operator*=(foo&);
...
The first operator:
...
$ c++filt _ZN3foomlERS_
foo::operator*(foo&)
...
matches address 0x410250 which is defined here in the CU in the exec:
...
<1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram)
<10f2> DW_AT_specification: <alt 0x93>
<10f6> DW_AT_decl_line : 72
<10f7> DW_AT_decl_column : 7
<10f7> DW_AT_object_pointer: <0x1106>
<10f9> DW_AT_low_pc : 0x410250
<1101> DW_AT_high_pc : 32
<1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
<1104> DW_AT_call_all_calls: 1
...
and declared here in the PU in the .dwz file:
...
<2><93>: Abbrev Number: 20 (DW_TAG_subprogram)
<94> DW_AT_external : 1
<94> DW_AT_name : operator*
<98> DW_AT_decl_file : 2
<98> DW_AT_decl_line : 10
<99> DW_AT_decl_column : 9
<9a> DW_AT_linkage_name: _ZN3foomlERS_
<9e> DW_AT_accessibility: 1 (public)
<9e> DW_AT_declaration : 1
<9e> DW_AT_object_pointer: <0xa2>
...
When creating a new symbol for the operator, the DW_AT_decl_file attribute is
looked up, and found to be 2.
The 2 is supposed to be mapped using the PU, which has this file name table:
...
The File Name Table (offset 0x78, lines 3, columns 2):
Entry Dir Name
0 0 <dwz>
1 1 stddef.h
2 2 cplusfuncs.cc
...
Instead, it's mapped using the CU, which has this file name table:
...
The File Name Table (offset 0x34, lines 3, columns 2):
Entry Dir Name
0 1 cplusfuncs.cc
1 1 cplusfuncs.cc
2 2 stddef.h
...
This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where
the same problem happens for two CUs.
Fix this by using the correct file name table.
Add a dwarf assembly test-case for PR25771.
Tested on aarch64-linux.
Reviewed-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814
Add handling of '.' in gdb/contrib/spellcheck.sh.
While we're at, simplify the sed invocation by using a single s command
instead of 3 s commands.
Also introduce sed_join and grep_join.
Fix the following common misspellings:
...
bandwith -> bandwidth
emmitted -> emitted
immediatly -> immediately
suprize -> surprise
thru -> through
transfered -> transferred
...
Verified with shellcheck.
Speed up gdb/contrib/shellcheck.sh by caching the grep pattern.
Without cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m2,750s
user 0m0,013s
sys 0m0,032s
...
and with cached grep pattern:
...
$ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c
real 0m0,192s
user 0m0,022s
sys 0m0,024s
...
Tested on aarch64-linux.
Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell
check and bail out ASAP with an exit code of 1 if misspelled words were
found, or 0 otherwise.
Verified with shellcheck.
A question was asked on stackoverflow.com about the guile function
get-basic-type[1] which is mentioned in the docs along with an example
of its use.
The problem is, the function was apparently never actually added to
GDB. But it turns out that it's pretty easy to implement, so lets add
it now. Better late than never.
The implementation mirrors the Python get_basic_type function. I've
added a test which is a copy of the documentation example.
One issue is that the docs suggest that the type will be returned as
just "int", however, I'm not sure what this actually means. It makes
more sense that the function return a gdb:type object which would be
represented as "#<gdb:type int>", so I've updated the docs to show
this output.
[1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session
Reviewed-By: Kevin Buettner <kevinb@redhat.com>
When building gdb with -std=c++20 I run into:
...
gdb/dwarf2/cooked-index.c: In lambda function:
gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \
‘[=]’ is deprecated in C++20 [-Werror=deprecated]
471 | gdb::thread_pool::g_thread_pool->post_task ([=] ()
| ^
gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture
...
Fix this and two more spots by removing the capture default, and explicitly
listing all captures.
Tested on x86_64-linux.
There is an invalid assumption within 'maint info inline-frames' which
triggers an assert:
(gdb) stepi
0x000000000040119d 18 printf ("Hello World\n");
(gdb) maintenance info inline-frames
../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
----- Backtrace -----
... etc ...
The problem is this assert:
/* Stopped threads always have cached inline_state information. */
gdb_assert (it != inline_states.end ());
If you check out infrun.c and look in handle_signal_stop for the call
to skip_inline_frames then you'll find a rather large comment that
explains that we don't always compute the inline state information for
performance reasons. So the assertion is not valid.
I've updated the code so that if there is cached information we use
that, but if there is not then we just create our own information for
the current $pc of the current thread.
This means that, if there is cached information, GDB still correctly
shows which frame the inferior is in (it might not be in the inner
most frame).
If there is no cached information we will always display the inferior
as being in the inner most frame, but that's OK, because if
skip_inline_frames has not been called then GDB will have told the
user they are in the inner most frame, so everything lines up.
I've extended the test to check 'maint info inline-frames' after a
stepi which would previously have triggered the assertion.
I searched for spots using ".reset (new ...)" and replaced most of
these with std::make_unique. I think this is a bit cleaner and more
idiomatic.
Regression tested on x86-64 Fedora 40.
Reviewed-By: Klaus Gerlicher<klaus.gerlicher@intel.com>
This changes the DWARF reader to capture the current working directory
and the current debug directory. This avoids races when the DWARF
reader is working in the background.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
This patch adds a cwd paramter to openp, so that the current directory
can be passed in by the caller. This is useful when background
threads call this function -- they can then avoid using the global and
thus avoid races with the user using "cd".
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716
While trying to substitute some std::vector type A in the code with a
gdb::array_view:
...
- using A = std::vector<T>
+ using A = gdb::array_view<T>
....
I ran into the problem that the code was using A::iterator while
gdb::array_view doesn't define such a type.
Fix this by:
- adding types gdb::array_view::iterator and gdb::array_view::const_iterator,
- using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is
usual, and
- using them explicitly in a unit test.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
When building gdb with -std=c++20, I run into:
...
In file included from /usr/include/guile/2.0/libguile/__scm.h:479,
from /usr/include/guile/2.0/libguile.h:31,
from /data/vries/gdb/src/gdb/guile/guile-internal.h:30,
from /data/vries/gdb/src/gdb/guile/guile.c:37:
/usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \
scm_cell(scm_t_bits, scm_t_bits)’:
/usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \
assignment with ‘volatile’-qualified left operand is deprecated \
[-Werror=volatile]
98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x))
| ~~~~~~~~~~~~~~~~~~~^~~~~
...
This was reported upstream [1].
Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the
default SCM_DEBUG_TYPING_STRICTNESS == 1.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR guile/30767
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333
Consider test-case gdb.dwarf2/local-var.exp. The corresponding source
contains a function with a local variable:
...
program test
logical :: local_var
local_var = .TRUE.
end
...
Currently, the local variable shows up in the cooked index:
...
[2] ((cooked_index_entry *) 0xfffec40063b0)
name: local_var
canonical: local_var
qualified: local_var
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0xa3
parent: ((cooked_index_entry *) 0xfffec4006380) [test]
...
making the cooked index larger than necessary.
Fix this by skipping it in cooked_indexer::index_dies.
Tested on aarch64-linux.
PR symtab/32276
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276
Say we simulate a bad alloc in gdb_bfd_init_data:
...
+ {
+ static bool throw_bad_alloc = true;
+ if (throw_bad_alloc)
+ {
+ throw_bad_alloc = false;
+
+ va_list dummy;
+ throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy));
+ }
+ }
gdata = new gdb_bfd_data (abfd, st);
...
That works out fine for doing "file a.out" once:
...
$ gdb -q -batch -ex "file a.out"
bad alloc
$
...
but doing so twice get us:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
Fatal signal: Segmentation fault
----- Backtrace -----
0x5183f7 gdb_internal_backtrace_1
/home/vries/gdb/src/gdb/bt-utils.c:121
0x5183f7 _Z22gdb_internal_backtracev
/home/vries/gdb/src/gdb/bt-utils.c:167
0x62329b handle_fatal_signal
/home/vries/gdb/src/gdb/event-top.c:917
0x6233ef handle_sigsegv
/home/vries/gdb/src/gdb/event-top.c:990
0xfffeffba483f ???
0x65554c eq_bfd
/home/vries/gdb/src/gdb/gdb_bfd.c:231
0xeaca77 htab_find_with_hash
/home/vries/gdb/src/libiberty/hashtab.c:597
0x657487 _Z12gdb_bfd_openPKcS0_ib
/home/vries/gdb/src/gdb/gdb_bfd.c:580
0x6272d7 _Z16exec_file_attachPKci
/home/vries/gdb/src/gdb/exec.c:451
0x627e67 exec_file_command
/home/vries/gdb/src/gdb/exec.c:550
0x627f23 file_command
/home/vries/gdb/src/gdb/exec.c:565
Segmentation fault (core dumped)
$
...
The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache:
...
if (bfd_sharing)
{
slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT);
gdb_assert (!*slot);
*slot = abfd;
}
gdb_bfd_init_data (abfd, &st);
...
while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is
not properly initialized.
Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after
a successful call to gdb_bfd_init_data, such that we get:
...
$ gdb -q -batch -ex "file a.out" -ex "file a.out"
bad alloc
$
...
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
While looking at the cooked index entry for local variable l4 of function test
in test-case gdb.fortran/logical.exp:
...
$ gdb -q -batch outputs/gdb.fortran/logical/logical \
-ex "maint print objfiles"
...
[9] ((cooked_index_entry *) 0x7fc6e0003010)
name: l4
canonical: l4
qualified: l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test]
...
I noticed that while the entry does have a parent, that's not reflected in the
qualified name.
This makes it harder to write test-cases that check the parent of a cooked
index entry.
This is due to the implementation of full_name, which skips printing
parents if the language does not specify an appropriate separator.
Fix this by using "::" as default separator, getting us instead:
...
[9] ((cooked_index_entry *) 0x7f94ec0040c0)
name: l4
canonical: l4
qualified: test::l4
DWARF tag: DW_TAG_variable
flags: 0x2 [IS_STATIC]
DIE offset: 0x17c
parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test]
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run
into:
...
(gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1
get_compiler_info: gcc-7-5-0
p Float(Another_Fixed) = Float(Another_Delta * 5)^M
No definition of "another_delta" in current context.^M
(gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed
...
This is a regression since commit 1411185a57 ("Introduce and use
gnat_version_compare"), which did:
...
# This failed before GCC 10.
- if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} {
+ if {$scenario == "all" && [gnat_version_compare < 10]} {
gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \
"value of another_fixed"
}
...
Fix this by using gnat_version_compare >= 10 instead.
Tested on x86_64-linux, with gcc 7 - 13.
While testing a modified GNAT, I found that this test in
fun_renaming.exp was returning 0 for GCC 13:
if {[test_compiler_info {gcc-6*}]}
This patch introduces a new, more robust way to check the GNAT
compiler version, and changes the gda.ada tests to use it. A small
update to version_compare was also needed.
Note that, in its current form, this new code won't really interact
well with non-GCC compilers (specifically gnat-llvm). This doesn't
seem like a major issue at this point, though, because gnat-llvm
doesn't properly emit debuginfo yet, and when it does, more changes
will be needed in these tests anyway.
Reviewed-by: Keith Seitz <keiths@redhat.com>
A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations
calls in update_breakpoint_locations", started checking if GDB correctly
relocates a breakpoint from inferior 1's declaration of the function
"bar" to inferior 2's declaration.
Unfortunately, inferior 2 never calls bar in its regular execution, and
because of that, clang would optimize that whole function away, making
it so there is no location for the breakpoint to be relocated to.
This commit changes the .c file so that the function is not optimized
away and the test fully passes with clang. It is important to actually
call bar instead of using __attribute__((used)) because the latter
causes the breakpoint locations to be inverted, 3.1 belongs to inferior
2 and 3.2 belongs to inferior 1, which will cause an unrelated failure.
Approved-By: Andrew Burgess <aburgess@redhat.com>
Before this commit, the function frame_unwind_try_unwinder would return
an int, where 1 meant the unwinder works, and 0 it doesn't. This is just
a boolean with extra steps, so this commit updates the function to
return bool instead.
There is a single declaration of set_tdesc_osabi that is shared
between gdbserver/ and gdb/, this declaration takes a 'const char *'
argument which is the string representing an osabi.
Then in gdb/ we have an overload of set_tdesc_osabi which takes an
'enum gdb_osabi'.
In this commit I change the shared set_tdesc_osabi to be the version
which takes an 'enum gdb_osabi', and I remove the version which takes
a 'const char *'. All users of set_tdesc_osabi are updated to pass an
'enum gdb_osabi'.
The features/ code, which is generated from the xml files, requires a
new function to be added to osabi.{c,h} which can return a string
representation of an 'enum gdb_osabi'. With that new function in
place the features/ code is regenerated.
This change is being made to support the next commit. In the next
commit gdbserver will be updated to call set_tdesc_osabi in more
cases. The problem is that gdbserver stores the osabi as a string.
The issue here is that a typo in the gdbserver/ code might go
unnoticed and result in gdbserver sending back an invalid osabi
string.
To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
set_tdesc_osabi function. With that requirement in place it seems to
make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.
There should be no user visible changes after this commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
In future commits I want to call set_tdesc_osabi from gdbserver/
code. Currently the only version of set_tdesc_osabi available to
gdbserver takes a string representing the osabi.
The problem with this is that, having lots of calls to set_tdesc_osabi
which all take a string is an invite for a typo to slip in. This typo
could potentially go unnoticed until someone tries to debug the wrong
combination of GDB and gdbserver, at which point GDB will fail to find
the correct gdbarch because it doesn't understand the osabi string.
It would be better if the set_tdesc_osabi calls in gdbserver could
take an 'enum gdb_osabi' value and then convert this to the "correct"
string internally. In this way we are guaranteed to always have a
valid, known, osabi string.
This commit splits the osabi related code, which currently lives
entirely on the GDB side, between gdb/ and gdbsupport/. I've moved
the enum definition along with the array of osabi names into
gdbsupport/. Then all the functions that access the names list, and
which convert between names and enum values are also moved.
I've taken the opportunity of this move to add a '.def' file which
contains all the enum names along with the name strings. This '.def'
file is then used to create 'enum gdb_osabi' as well as the array of
osabi name strings. By using a '.def' file we know that the enum
order will always match the name string array.
This commit is just a refactor, there are no user visible changes
after this commit. This commit doesn't change how gdbserver sets the
target description osabi string, that will come in the next commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
There are two versions of the set_tdesc_osabi function in GDB:
void
set_tdesc_osabi (struct target_desc *target_desc, const char *name)
{
set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name));
}
void
set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi)
{
target_desc->osabi = osabi;
}
In the gdb/features/ files we call the second of these functions, like
this:
set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux"));
This can be replaced with a call to the first set_tdesc_osabi
function, so lets do that. I think that this makes the features/ code
slightly simpler and easier to understand.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into:
...
(gdb) awatch a^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint
rwatch b^M
Can't set read/access watchpoint when hardware watchpoints are disabled.^M
(gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint
continue^M
Continuing.^M
^M
Program received signal SIGSEGV, Segmentation fault.^M
0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) FAIL: $exp: continue until exit
...
Using "maint info break", we can see that the two failed attempts to set a
watchpoint each left behind a stale "watchpoint scope" breakpoint:
...
-5 watchpoint scope del y 0xf7ec569a inf 1
-5.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
-6 watchpoint scope del y 0xf7ec569a inf 1
-6.1 y 0xf7ec569a inf 1
stop only in stack frame at 0xfffef4f8
...
The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the
same happens if we:
- have can-use-hw-watchpoints == 1,
- set one of the watchpoints, and
- continue to exit.
The problem is missing symbol info on libc which is supposed to tell which
code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV
disappears.
Extend the test-case to check the "maint info break" command before and after
the two failed attempts, to make sure that we catch the stale
"watchpoint scope" breakpoints also on x86_64-linux.
Fix this in watch_command_1 by moving creation of the "watchpoint scope"
breakpoint after the call to update_watchpoint.
Tested on x86_64-linux.
PR breakpoints/31860
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860
When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get:
...
FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1
FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent
FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2
...
The problem is that the debug info produced by clang does not contain any
references to enumerators val1 and val2, or the corresponding enumeration
types.
Instead, the variables u1 and u2 are considered to be simply of type int:
...
<1><fb>: Abbrev Number: 2 (DW_TAG_variable)
<fc> DW_AT_name : u1
<fd> DW_AT_type : <0x106>
<101> DW_AT_external : 1
<103> DW_AT_location : (DW_OP_addrx <0>)
<1><106>: Abbrev Number: 3 (DW_TAG_base_type)
<107> DW_AT_name : int
<108> DW_AT_encoding : 5 (signed)
<109> DW_AT_byte_size : 4
<1><10a>: Abbrev Number: 2 (DW_TAG_variable)
<10b> DW_AT_name : u2
<10c> DW_AT_type : <0x106>
<110> DW_AT_external : 1
<112> DW_AT_location : (DW_OP_addrx <0x1>)
...
Fix this by checking whether val1 and val2 are present in the cooked index
before checking whether they have the correct parent.
This cannot be expressed efficiently with gdb_test_lines, so factor out
gdb_get_lines and use that instead.
The test-case still calls "maint print objfiles" twice, but the first time is
for have_index. We should probably use a gdb_caching_proc for this.
Tested on aarch64-linux.
Reported-By: Guinevere Larsen <guinevere@redhat.com>
Reviewed-By: Keith Seitz <keiths@redhat.com>
Tested-By: Guinevere Larsen <guinevere@redhat.com>
I ran the testsuite in an environment simulating a stressed system in
combination with check-read1. This exposes a few more FAILs.
Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output.
Tested on x86_64-linux.
On aarch64-linux, with make target check-read1, I run into:
...
(gdb) info reg vector^M
...
d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout)
0, u = 0, s = 0}^M
...
The problem is that while (as documented) the corresponding gdb_test_multiple
doesn't work for vector registers, it doesn't skip them either. This causes
the timeout, and it also causes the registers after a vector register not to
be found.
Fix this by using -lbl style matching.
Make which reggroups and registers are found more explicit using verbose -log,
which makes us notice that regnames with underscores are skipped, so fix that
as well.
While we're at it, this:
...
set invalid_register_re "Invalid register .*"
...
and this:
...
-re $invalid_register_re {
fail "$test (unexpected invalid register response)"
}
...
means that the prompt may or may not be consumed. Fix this by limiting the
regexp to one line, and using exp_continue.
While we're at it, improve readability of the complex regexp matching a single
register by factoring out regexps.
Tested on aarch64-linux and x86_64-linux.
This changes a few implementations of "info proc mappings" to use
ui-out tables rather than printf.
Note that NetBSD and FreeBSD also use printfs here, but since I can't
test these, I didn't update them.
Approved-By: Andrew Burgess <aburgess@redhat.com>
When running test-case gdb.base/break-interp.exp with check-read1, I run into:
...
(gdb) info files^M
...
0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout)
pieNO.d/libc.so.6^M
...
The code has two adaptations to deal with the large output:
- nested gdb_test_multiple, and
- an exp_continue in the inner gdb_test_multiple.
The former seems unnecessary, and the latter doesn't trigger often enough
because of an incomplete hex number regexp, causing the timeout.
Get rid of both of these, and use -lbl instead.
Tested on x86_64-linux.
Include the value of configuration flag --enable-targets in the output
of GDB command 'show configuration' and also in the output printed for
'gdb --configuration'. This will make it easier to see how GDB was
built.
No tests added or updated as we can't really check for a specific flag
appearing or not appearing on the configuration output. But we do
print the configuration within lib/gdb.exp to check which features are
built into GDB, so if this change broke configuration printing then
plenty of tests should stop working (they don't).
Approved-By: Tom Tromey <tom@tromey.com>
The commit:
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
added a couple of calls to breakpoint::clear_locations() inside
update_breakpoint_locations().
The intention of these calls was to avoid leaving redundant locations
around when a thread- or inferior-specific breakpoint was switched
from one thread or inferior to another.
Without the clear_locations() calls the tests gdb.multi/tids.exp and
gdb.multi/pending-bp.exp have some failures. A b/p is changed such
that the program space it is associated with changes. This triggers a
call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be
the new program space. As a result GDB correctly calculates the new
locations and adds these to the breakpoint, but the old locations, in
the old program space, are incorrectly retained. The call to
clear_locations() solves this by deleting the old locations.
However, while working on another patch I realised that the approach
taken here is not correct. The FILTER_PSPACE argument passed to
breakpoint_re_set_one() and then on to update_breakpoint_locations()
might not be the program space to which the breakpoint is associated.
Consider this example:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) start
Temporary breakpoint 1 at 0x401198: file hello.c, line 18.
Starting program: /tmp/hello.x
Temporary breakpoint 1, main () at hello.c:18
18 printf ("Hello World\n");
(gdb) break main thread 1
Breakpoint 2 at 0x401198: file hello.c, line 18.
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000401198 in main at hello.c:18
stop only in thread 1
(gdb) add-inferior -exec /tmp/hello.x
[New inferior 2]
Added inferior 2 on connection 1 (native)
Reading symbols from /tmp/hello.x...
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y <PENDING> main
stop only in thread 1.1
Notice that after creating the second inferior and loading a file the
thread-specific breakpoint was incorrectly made pending. Loading the
exec file in the second inferior triggered a call to
breakpoint_re_set() with the new, second, program space as the
current_program_space.
This program space ends up being passed to
update_breakpoint_locations().
In update_breakpoint_locations this condition is true:
if (all_locations_are_pending (b, filter_pspace) && sals.empty ())
and so we end up discarding all of the locations for this breakpoint,
making the breakpoint pending.
What we really want to do in update_breakpoint_locations() is, for
thread- or inferior- specific breakpoints, delete any locations which
are associated with a program space that this breakpoint is NOT
associated with.
But then I realised the answer was easier than that.
The ONLY time that a b/p can have locations associated with the
"wrong" program space like this is at the moment we change the thread
or inferior the b/p is associated with by calling
breakpoint_set_thread() or breakpoint_set_inferior().
And so, I think the correct solution is to hoist the call to
clear_locations() out of update_breakpoint_locations() and place a
call in each of the breakpoint_set_{thread,inferior} functions.
I've done this, and added a couple of new tests. All of which are
now passing.
Approved-By: Tom Tromey <tom@tromey.com>
When running test-case gdb.ada/tagged-lookup.exp with target board readnow and
make target check-read1:
...
$ ( cd build/gdb; \
make check-read1 \
RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" )
...
I run into:
...
(gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1
print *the_local_var^M
$1 = (n => 2)^M
(gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded
...
The problem is that the corresponding gdb_test_multiple uses line-by-line
matching (using -lbl) which doesn't work well with the multiline pattern
matching both the prompt and the line before it:
...
-re -wrap ".* = \\\(n => $decimal\\\)" {
...
Fix this by making it a one-line pattern:
...
-re -wrap "" {
...
While we're at it, replace an if-then-pass-else-fail with a gdb_assert.
Tested on aarch64-linux.
When running test-case gdb.dwarf2/enum-type-c++.exp with target board
cc-with-debug-types, we run into:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
because val1 has no parent:
...
[31] ((cooked_index_entry *) 0x7efedc002e90)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
...
[37] ((cooked_index_entry *) 0x38ffd280)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0xef
parent: ((cooked_index_entry *) 0)
...
There are two entries, which seems to be an inefficiency, but for now let's
focus on the correctness issue.
The debug info for val1 looks like this:
...
<1><cb>: Abbrev Number: 2 (DW_TAG_namespace)
<cc> DW_AT_name : ns
<cf> DW_AT_declaration : 1
<2><d3>: Abbrev Number: 12 (DW_TAG_class_type)
<d4> DW_AT_name : A
<d6> DW_AT_declaration : 1
<3><d6>: Abbrev Number: 13 (DW_TAG_enumeration_type)
<db> DW_AT_declaration : 1
<1><dd>: Abbrev Number: 14 (DW_TAG_enumeration_type)
<e7> DW_AT_specification: <0xd6>
<2><ef>: Abbrev Number: 5 (DW_TAG_enumerator)
<f0> DW_AT_name : val1
<f4> DW_AT_const_value : 1
...
Fix this by:
- adding a cooked index entry for DIE 0xcb (and consequently for child DIE
0xd3), by marking it interesting,
- making sure that the entry for DIE 0xcb has a name, and
- using the entry for DIE 0xd3 as parent entry for DIE 0xdd.
Tested on aarch64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of
DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in
test-case gdb.dwarf2/enum-type.exp, 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)
...
This happens here in cooked_indexer::index_dies:
...
info_ptr = recurse (reader, info_ptr,
is_enum_class ? this_entry : parent_entry,
fully);
...
when we're passing down a nullptr parent_entry, while the parent of this_entry
is deferred.
Fix this in cooked_indexer::index_dies by passing down a deffered parent
instead, such that we get:
...
[27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M
name: val1^M
canonical: val1^M
qualified: ns::val1^M
DWARF tag: DW_TAG_enumerator^M
flags: 0x0 []^M
DIE offset: 0x124^M
parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M
...
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Add two more separators in spellcheck.sh: colon and comma.
Doing so triggers the "inbetween->between" rule, which gives an incorrect
result. Override this with "inbetween->between, in between, in-between" [1],
in a new file gdb/contrib/common-misspellings.txt.
Fix the following common misspellings:
...
everytime -> every time
sucess -> success
thru -> through
transfered -> transferred
inbetween -> between, in between, in-between
...
Verified with spellcheck.sh. Tested on x86_64-linux.
[1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/
While trying to add more separators here:
...
# Separators: space, slash, tab.
grep_separator=" |/| "
sed_separator=" \|/\|\t"
...
I mistakingly used "|" instead of "\|" in sed_separator.
Factor out new variables grep_or and sed_or, and construct the grep_separator
and sed_separator variables by joining the elements of a list using grep_or
and sed_or.
Verified with shellcheck, and tested by rerunning on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
With a gdb build with -fsanitize=thread, and test-case
gdb.python/py-inferior.exp I run into:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
maximum supported size of 0x10000000000^M
...
There's already a workaround for this using ASAN_OPTIONS, and apparently the
same is needed for TSAN_OPTIONS.
Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.
Likewise in gdb.dap/memory.exp.
Tested on x86_64-linux.
This patch introduces ADR to the Modula-2 language interface.
It return the address of the parameter supplied.
The patch also contains a dejagnu test for ADR.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
I came across a table containing common misspellings [1], and wrote a script to
detect and correct these misspellings.
The table also contains entries that have alternatives, like this:
...
addres->address, adders
...
and for those the script prints a TODO instead.
The script downloads the webpage containing the table, extracts the table and
caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it
over and over again.
Example usage:
...
$ gdb/contrib/spellcheck.sh gdb*
...
ChangeLog files are silently skipped.
Checked with shellcheck.
Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and
test run.
The results of running it are in the two following patches.
Reviewed-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines
After commit 68bbe11833, ELF symbols read via bfd_canonicalize_symtab
and similar functions which have bad st_name fields will have NULL in
the name rather than "(null)". gdb.base/bfd-errors.exp deliberately
creates a faulty shared library with st_name pointing outside of
.dynsym for some symbols, and thus now results in NULL symbol names.
This triggers a segv on string_buffer.assign(name). Fix that.
when I disable a breakpoint in VS Code the breakpoint is removed
instead. I compared the behavior to lldb-dap and disabled events when
removing a breakpoint. Now it is possible to disable and enable
breakpoints in VS Code.
While looking at the recent line number styling commit I noticed a few
places where we could add more file name styling. So lets do that.
Approved-By: Tom Tromey <tom@tromey.com>
There's currently code in gdb that checks if an expression evaluates
to a type. In some spots this is done by comparing the opcode against
OP_TYPE, but other spots more correctly also compare with OP_TYPEOF
and OP_DECLTYPE.
This patch cleans up this area, replacing opcode-checking with a new
method on 'operation'.
Generally, checking the opcode should be considered deprecated,
although it's unfortunately difficult to get rid of opcodes entirely.
I also took advantage of this change to turn eval_op_type into a
method, removing a bit of indirection.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This patch adds separate styling for line numbers. That is, whenever
gdb prints a source line number, it uses this style.
v2 includes a change to ensure that %ps works in query.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Reviewed-by: Keith Seitz <keiths@redhat.com>
I noticed that filename completion in the middle of a line doesn't
work as I would expect it too. For example, assuming '/tmp/filename'
exists, and is the only file in '/tmp/' then when I do the following:
(gdb) file "/tmp/filen<TAB>
GDB completes to:
(gdb) file "/tmp/filename"
But, if I type this:
(gdb) file "/tmp/filen "xxx"
Then move the cursor to the end of '/tmp/filen' and press <TAB>, GDB
will complete the line to:
(gdb) file "/tmp/filename "xxx"
But GDB will not insert the trailing double quote character.
The reason for this is found in readline/readline/complete.c in the
function append_to_match. This is the function that appends the
trailing closing quote character, however, the closing quote is only
inserted if the cursor (rl_point) is at the end (rl_end) of the line
being completed.
In this patch, what I do instead is add the closing quote in the
function gdb_completer_file_name_quote, which is called from readline
through the rl_filename_quoting_function hook. The docs for
rl_filename_quoting_function say (see 'info readline'):
"... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one
completion match, or 'MULT_MATCH'. Some functions use this to
decide whether or not to insert a closing quote character. ..."
This is exactly what I'm doing in this patch, and clearly this is not
an unusual choice. Now after completing a filename that is not at the
end of the line GDB will add the closing quote character if
appropriate.
I have managed to write some tests for this. I send a line of text to
GDB which includes a partial filename followed by a trailing string, I
then send the escape sequence to move the cursor left, and finally I
send the tab character.
Obviously, expect doesn't actually see the complete output with the
extra text "in place", instead expect sees the original line followed
by some escape sequences to reflect the cursor movement, then an
escape sequence to indicate that text is being inserted in the middle
of a line, followed by the new characters ... it's a bit messy, but I
think it holds together.
Reviewed-By: Tom Tromey <tom@tromey.com>
After the recent filename completion changes I noticed that the
following didn't work as expected:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
Now, I know that the 'file' command doesn't actually take multiple
filenames, but currently (and this was true before the recent filename
completion changes too) the completion function doesn't know that the
command only expects a single filename, and should complete any number
of filenames. And indeed, this works:
(gdb) file "/path/to/some/file" "/path/to/so<TAB>
In this case I quoted the second path, and now GDB is happy to offer
completions.
It turns out that the problem in the first case is an off-by-one bug
in gdb_completer_file_name_char_is_quoted. This function tells GDB if
a character within the line being completed is escaped or not. An
escaped character cannot be a word separator.
The algorithm in gdb_completer_file_name_char_is_quoted is to scan
forward through the line keeping track of whether we are inside double
or single quotes, or if a character follows a backslash. When we find
an opening quote we skip forward to the closing quote and then check
to see if we skipped over the character we are looking for, if we did
then the character is within the quoted string.
The problem is that this "is character inside quoted string" check
used '>=' instead if '>'. As a consequence a character immediately
after a quoted string would be thought of as inside the quoted string.
In our first example this means that the single white space character
after the quoted string was thought to be quoted, and was not
considered a word breaking character. As such, GDB would not try to
complete the second path. And indeed, if we tried this:
(gdb) file "/path/to/some/file" /path/to/so<TAB>
That is, place multiple spaces after the first path, then GDB would
consider the first space as quoted, but the second space is NOT
quoted, and would be a word break. Now GDB does complete the second
path.
By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this
bug is resolved, now the original example works and GDB will correctly
complete the second path.
For testing I've factored out the core of one testing proc, and I now
run those tests multiple times, once with no initial path, once with
an initial path in double quotes, once with an initial path in
single quotes, and finally, with an unquoted initial path.
Reviewed-By: Tom Tromey <tom@tromey.com>
Some of the gdb and testsuite files double include some headers. While
all headers use include guards, it helps a bit keeping the code base
tidy.
No functional change.
Approved-by: Kevin Buettner <kevinb@redhat.com>
[ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ]
When building the cooked index, gdb builds up a parent map.
This map is currently only visible at user level through the effect of using
it, but it's useful to be able to inspect it as well.
Add dumping of this parent map for "set debug dwarf-read 2".
As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board
debug-types.
The parent map looks like:
...
$ gdb -q -batch \
-iex "maint set worker-threads 0" \
-iex "set debug dwarf-read 2" \
outputs/gdb.dwarf2/enum-type-c++/enum-type-c++
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000037 0x20f27d30 (0x36: ec)
0x0000000000000051 0x0
0x000000000000008b 0x20f27dc0 (0x8a: A)
0x00000000000000a6 0x0
...
There's no parent entry at address 0xd6, which is part of what causes this:
...
(gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent
...
With the series containing the proposed fix applied [2], we get instead:
...
[dwarf-read] print_stats: Final m_all_parents_map:
map start:
0x0000000000000000 0x0
0x0000000000000026 0x7e0bdc0 (0x25: ns)
0x0000000000000036 0x0
0x0000000000000037 0x7e0bdf0 (0x36: ns::ec)
0x0000000000000051 0x0
0x000000000000007f 0x7e0be80 (0x7e: ns)
0x000000000000008a 0x0
0x000000000000008b 0x7e0beb0 (0x8a: ns::A)
0x00000000000000a6 0x0
0x00000000000000cc 0x7e0bf10 (0xcb: ns)
0x00000000000000d4 0x7e0bf40 (0xd3: ns::A)
0x00000000000000dc 0x7e0bf10 (0xcb: ns)
0x00000000000000dd 0x7e0bf40 (0xd3: ns::A)
0x00000000000000f6 0x0
...
and find at 0xd6 parent ns::A.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html
[2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html
Make the current program space references bubble up.
In collect_symtabs_from_filename, remove the calls to
set_current_program_space and just pass the relevant pspaces.
This appears safe to do, because nothing in the `collector` callback
cares about the current pspace.
Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb
Reviewed-by: Keith Seitz <keiths@redhat.com>
For a long time Fedora GDB has carried an out of tree patch which
checks for memory leaks in gdb.Inferior.read_memory(). At one point
in the distant past GDB did have a memory leak in this code, but this
was first fixed in commit:
commit 655e820cf9a039ee55325d9e1f8423796d592b4b
Date: Wed Mar 28 17:38:07 2012 +0000
* python/py-inferior.c (infpy_read_memory): Remove cleanups and
explicitly free 'buffer' on exit paths. Decref 'membuf_object'
before returning.
And the code has changed a lot since then, but the leak is still
fixed. Unfortunately, this commit didn't have any associated tests.
The original Fedora test wasn't really suitable for upstream, it was
reading /proc/PID/... to figure out if there was a leak or not.
However, we already have gdb.python/py-inferior-leak.exp in upstream
GDB, which makes use of the Python tracemalloc module to check for
memory leaks in a corner of the Python API, so I figured it wouldn't
hurt to rewrite the test in the same style.
And so here is a test for a bug which was closed 12 years ago. This
detects if the gdb.Inferior.read_memory() call leaks any memory.
I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last
line which currently looks like this:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ());
and instead doing:
return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ());
The use of "release" here will mean we no longer decrement the
reference count on membuf_obj before returning from the function. As
a consequence the membuf_obj will not be garbage collected. With this
hack in place the new test will fail.
The Python script in the new test is mostly a copy&paste from
py-inferior-leak.py with the core changed to do a memory read instead
of inferior creation. I did consider rewriting both tests into a
single file, maybe, py-memory-leak.py, which would make it easier to
add additional similar tests in the future. For now I've held off
doing that, but if this gets merged then I _might_ revisit this idea.
If folk feel that this new test should only be accepted if I do this
rewrite then let me know and I can get that done.
On copyright date ranges: The .exp and .py scripts are new enough for
this commit that I've dated them 2024. The .c source script is lifted
directly from the old Fedora patch, so I've retained the original 2014
start date for that file only.
Approved-By: Tom Tromey <tom@tromey.com>
With gdb 15.1, python sys.exit no longer makes gdb exit:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
Python Exception <class 'SystemExit'>: 2
Error occurred in Python: 2
$1 = 123
0
...
This is a change in behaviour since commit a207f6b3a3 ("Rewrite "python"
command exception handling"), first available in gdb 15.1.
This patch reverts to the old behaviour by handling PyExc_SystemExit in
gdbpy_handle_exception, such what we have instead:
...
$ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $?
2
...
Tested on x86_64-linux, with python 3.6 and 3.13.
Tested-By: Guinevere Larsen <blarsen@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
PR python/31946
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
and glibc (since v2.35). Let's now remove MPX support in GDB completely.
This includes the removal of:
- MPX functionality including register support
- deprecated mpx commands
- i386 and amd64 implementation of the hooks report_signal_info and
get_siginfo_type
- tests
- and pretty printer.
We keep MPX register numbers to not break compatibility with old gdbservers.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
Removing the pretty printer (bound_registers.py) in the next commit
leads to failures due to a missing import of 'gdb.printing':
"AttributeError: module 'gdb' has no attribute 'printing'".
Add this import to each file requiring it, as it's not imported by the
pretty-printer anymore.
Approved-By: Andrew Burgess <aburgess@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>
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>
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>
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>
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.
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
Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only
necessary for gcc 8 and 9.
Fix this by limiting the xfail to those releases.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
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
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.
Fix this by dropping the -readnow.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
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.
Approved-By: Tom Tromey <tom@tromey.com>
Following
commit 6cce025114
Date: Fri Mar 3 19:03:15 2023 +0000
gdb: only insert thread-specific breakpoints in the relevant inferior
... when building amd-dbgapi-target.c:
CXX amd-dbgapi-target.o
/home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override
486 | void re_set () override;
| ^~~~~~
Update the signature to match the base.
Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692
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 4e417d7bb1 ("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
Consider test-case:
...
namespace ns {
enum class ec {
val2 = 2
};
}
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 4e417d7bb1 ("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
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 4e417d7bb1 ("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
Commit f89276a2f3 ("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>
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.
Approved-by: Kevin Buettner <kevinb@redhat.com>
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.
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:
list.emplace (pos, "hello", 2);
rather than
list.insert (pos, std::make_unique<Foo> ("hello", 2));
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>
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.
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`:
return (CORE_ADDR (this->unrelocated_address ())
+ objfile->section_offsets[this->section_index ()]);
A section index of -29445 is suspicious. The minimal_symbol at play
here is:
(top-gdb) p m_name
$1 = 0x521001de10af "_sinittext"
So I restarted debugging, breaking on:
(top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name)
And I see that weird -29445 value:
(top-gdb) frame
#0 general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611
611 { m_section = idx; }
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.
With that fixed, I get:
(gdb) info func
All defined functions:
Non-debugging symbols:
0xffffffff81000000 _stext
0xffffffff82257000 _sinittext
0xffffffff822b4ebb _einittext
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165
Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>
Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple
to parse this cooked_index_entry:
...
[5] ((cooked_index_entry *) 0x7f01f0004040)^M
name: v^M
canonical: v^M
qualified: ns::v^M
DWARF tag: DW_TAG_variable^M
flags: 0x2 [IS_STATIC]^M
DIE offset: 0xcb^M
parent: ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M
...
which allows us to verify that the entry has a parent.
After commit 8f258a6c97 ("[gdb/symtab] Dump qualified name of
cooked_index_entry") that's no longer necessary.
Simplify this by checking for ns::v instead.
While we're at it, also fix the test-case for target boards readnow,
cc-with-gdb-index and cc-with-debug-names.
Tested on x86_64-linux.
In gdb.base/corefile-buildid.exp, in the function
do_corefile_buildid_tests, if we fail to find the build-id for the
test binary then we call 'untested', but then push on with the test,
which inevitably fails as the rest of the test depends on having found
the build-id.
I think we're missing a 'return' after the call to 'untested' which
I've now added.
Also I noticed that we call build_id_debug_filename_get and then
manually remove '.debug' from the end. This is no longer necessary,
we can just ask build_id_debug_filename_get to not add the suffix.
The commit:
commit 29c7078711
Date: Sun Sep 8 07:46:09 2024 +0200
[gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp
Highlighted that in some cases we might be running on a system with an
older version of Python (earlier than 3.7), and on a system for which
the curses library has not been installed.
In these circumstances the gdb.missing_debug module will not load as
it uses curses to provide isalnum() and isascii() functions.
To avoid this problem I propose that we copy the isalnum() and
isascii() from the Python curses library. These functions are
basically trivial and removing the curses dependency means GDB will
work in more cases without increasing its dependencies.
I did consider keeping the uses of curses and only having the function
definitions be a fallback for when the curses library failed to load,
but this felt like overkill. The function definitions are both tiny
and I think "obvious" given their specifications, so I figure we might
as well just use our own definitions if they are not available as
builtin methods on the str class.
For testing I changed this line:
if sys.version_info >= (3, 7):
to
if sys.version_info >= (3, 7) and False:
then reran gdb.python/py-missing-debug.exp, there were no failures.
Approved-By: Tom de Vries <tdevries@suse.de>
When running test-case gdb.xml/tdesc-regs.exp on riscv64-linux, I get:
...
(gdb) set tdesc file single-reg.xml^M
warning: Architecture rejected target-supplied description^M
(gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml
UNSUPPORTED: gdb.xml/tdesc-regs.exp: register tests
...
The FAIL and UNSUPPORTED are produced here:
...
# If no core registers were specified, assume this target does not
# support target-defined registers. Verify that we get a warning if
# we try to use them. This not only tests the warning, but also
# reminds maintainers to add test support when they add the feature.
if {[string equal ${core-regs} ""]} {
gdb_test "set tdesc file $single_reg_xml" \
"warning: Target-supplied registers are not supported.*" \
"set tdesc file single-reg.xml"
unsupported "register tests"
return 0
}
...
The test-case contains target-specific setting of the core-regs variable, and
adding this for riscv64 bypasses this code and makes the test-case pass.
However, without that change, the test-case shouldn't produce a FAIL since
gdb isn't doing anything wrong.
Fix this by producing instead:
...
PASS: $exp: set tdesc file single-reg.xml
UNSUPPORTED: $exp: register tests (missing architecture-specific core-regs setting)
...
Tested on riscv64-linux.
On x86_64-linux, with gcc 7.5.0 and CFLAGS/CXXFLAGS="-O0 -g -Wall" I ran into
a build breaker:
...
gdb/corelow.c: In member function ‘void mapped_file_info::add(const char*, const char*, const char*, std::vector<mem_range>&&, const bfd_build_id*)’:
gdb/corelow.c:1822:27: error: unused variable ‘it’ [-Werror=unused-variable]
const auto [it, inserted]
^
...
Fix this by dropping the variable it.
Tested on x86_64-linux.
Reviewed-By: Lancelot Six<lancelot.six@amd.com>
Currently, the callers of ada_identical_enum_types_p must check that
both enum types have the same number of members. In another series
I'm working on, it was convenient to move this check into the callee
instead; and I broke this patch out to make that series a little
simpler.
Approved-By: Tom de Vries <tdevries@suse.de>
This moves the declaration of 'i' into the 'for' loops in
ada_identical_enum_types_p. This is just a trivial cleanup.
Approved-By: Tom de Vries <tdevries@suse.de>
