From the commit 667ed4b14d onward, instead
of normal name GDB looks for the "jit_descriptor" linkage name in the JIT
code initialization. Without this change, the function
"lookup_minimal_symbol_linkage", only matches the non-static data. So in
case jit_debugger is static type then setting up breakpoint in the JIT code
fails. Issue is seen for the intel compilers, where jit_debug_descriptor has
static type i.e. "mst_file_data". Hence lookup_minimal_symbol_linkage returns
nullptr for it. So, in this case breakpoint does not hit in the JIT code.
To resolve this, the commit introduces a new boolean argument to the
lookup_minimal_symbol_linkage function. This argument allows the function to
also match mst_file_data and mst_file_bss types when set to true. The
function is called with this new argument set to true only from JIT code
initialization handling, ensuring that the current behavior remains unchanged
for other cases. Because handling of static types of data symbols for all cases
result in regression for "gdb.base/print-file-var.exp" test.
Example of minsym for the JIT code emitted by the intel compilers where
lookup_minimal_symbol_linkage fails without this change because jit_debugger
type is "mst_file_data".
(top-gdb) p *msymbol
$1 = {<general_symbol_info> =
{m_name = 0x7fffcc77dc95 "__jit_debug_descriptor",
m_value = {ivalue = 84325936, block = 0x506b630,
bytes = 0x506b630 <error: Cannot access memory at address 0x506b630>,
address = 0x506b630, unrel_addr = (unknown: 0x506b630),
common_block = 0x506b630, chain = 0x506b630},
language_specific = {obstack = 0x0, demangled_name = 0x0},
m_language = language_unknown, ada_mangled = 0, m_section = 29},
m_size = 24, filename = 0x55555a751b70 "JITLoaderGDB.cpp",
m_type = mst_file_data, created_by_gdb = 0,
m_target_flag_1 = 0, m_target_flag_2 = 0, m_has_size = 1,
name_set = 1, hash_next = 0x55555b86e4f0, demangled_hash_next = 0x0}
Updated the test "jit-elf-so.exp" to test the static type of jit_descriptor
object.
Approved-By: Tom Tromey <tom@tromey.com>
Consider the following test-case:
...
$ cat test.c
int main (void) { return 0; }
$ clang -g -gsplit-dwarf test.c -o test
$ llvm-dwp -e test -o test.dwp
...
This runs into a segmentation fault:
...
$ gdb -q -batch test
Fatal signal: Segmentation fault
...
The segmentation fault happens because in read_dwo_str_index this line sets p
to nullptr:
...
const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer;
...
while the following code expects it to point to some data.
The section we're trying to read is:
...
(gdb) p reader->dwo_file->sections.str_offsets
$4 = {s = {section = 0xffffcc00a9d0, containing_section = 0xffffcc00a9d0},
buffer = 0x0, size = 28, virtual_offset = 0, readin = false, is_virtual = true}
...
At first glance, the section is not readin, but actually it is.
This is a virtual section, meaning part of a containing section:
...
(gdb) p *reader->dwo_file->sections.str_offsets.s.containing_section
$8 = {s = {section = 0xffffcc00cde8, containing_section = 0xffffcc00cde8},
buffer = 0xffffcc009650 "\030", size = 28, virtual_offset = 0, readin = true,
is_virtual = false}
...
which is readin.
Fix this in create_dwp_v2_or_v5_section by initializing the buffer of the
virtual section using the buffer of the containing section:
...
result.buffer = section->buffer + offset;
...
Unfortunately it's difficult to write a test-case for this. We'll have to
teach the dwarf assembler to generate dwp files.
Tested on aarch64-linux.
This is a partial fix for PR symtab/31497.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497
The entry PC for a DIE, e.g. an inline function, might not be the base
address of the DIE. Currently though, in block::entry_pc(), GDB
always returns the base address (low-pc or the first address of the
first range) as the entry PC.
This commit extends the block class to carry the entry PC as a
separate member variable. Then the DWARF reader is extended to read
and set the entry PC for the block. Now in block::entry_pc(), if the
entry PC has been set, this is the value returned.
If the entry-pc has not been set to a specific value then the old
behaviour of block::entry_pc() remains, GDB will use the block's base
address. Not every DIE will set the entry-pc, but GDB still needs to
have an entry-pc for every block, so the existing logic supplies the
entry-pc for any block where the entry-pc was not set.
The DWARF-5 spec for reading the entry PC is a super-set of the spec
as found in DWARF-4. For example, if there is no DW_AT_entry_pc then
DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base
address, which is DW_AT_low_pc or the first address in the first range
specified by DW_AT_ranges if there is no DW_AT_low_pc.
I have taken the approach of just implementing the DWARF-5 spec for
everyone. There doesn't seem to be any benefit to deliberately
ignoring a ranges based entry PC value for DWARF-4. If some naughty
compiler has emitted that, then lets use it.
Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5
allows an address or a constant, where the constant is an offset from
the base address. I allow both approaches for all DWARF versions.
There doesn't seem to be any downsides to this approach.
I ran into an issue when testing this patch where GCC would have the
DW_AT_entry_pc point to an empty range. When GDB parses the ranges
any empty ranges are ignored. As a consequence, the entry-pc appears
to be outside the address range of a block.
The empty range problem is certainly something that we can, and should
address, but that is not the focus of this patch, so for now I'm
ignoring that problem. What I have done is added a check: if the
DW_AT_entry_pc is outside the range of a block then the entry-pc is
ignored, GDB will then fall-back to its default algorithm for
computing the entry-pc.
If/when in the future we address the empty range problem, these
DW_AT_entry_pc attributes will suddenly become valid and GDB will
start using them. Until then, GDB continues to operate as it always
has.
An early version of this patch stored the entry-pc within the block
like this:
std::optional<CORE_ADDR> m_entry_pc;
However, a concern was raised that this, on a 64-bit host, effectively
increases the size of block by 16-bytes (8-bytes for the CORE_ADDR,
and 8-bytes for the std::optional's bool plus padding).
If we remove the std::optional part and just use a CORE_ADDR then we
need to have a "special" address to indicate if m_entry_pc is in use
or not. I don't really like using special addresses; different
targets can access different address ranges, even zero is a valid
address on some targets.
However, Bernd Edlinger suggested storing the entry-pc as an offset,
and I think that will resolve my concerns. So, we store the entry-pc
as a signed offset from the block's base address (the first address of
the first range, or the start() address value if there are now
ranges). Remember, ranges can be out of order, in which case the
first address of the first range might be greater than the entry-pc.
When GDB needs to read the entry-pc we can add the offset onto the
blocks base address to recalculate it.
With this done, on a 64-bit host, block only needs to increase by
8-bytes.
The inline-entry.exp test was originally contributed by Bernd here:
https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com
though I have made some edits, making more use of lib/gdb.exp
functions, making the gdb_test output patterns a little tighter, and
updating the test to run with Clang. I also moved the test to
gdb.opt/ as that seemed like a better home for it.
Co-Authored-By: Bernd Edlinger <bernd.edlinger@hotmail.de>
This patch ensures that all ordinary help strings are wrapped at 80
columns. For the most part this consists of changing code like this
(note the embedded \n and the trailing backslash without a newline):
-Manage the space-separated list of debuginfod server URLs that GDB will query \
-when missing debuginfo, executables or source files.\nThe default value is \
-copied from the DEBUGINFOD_URLS environment variable."),
... to end each line with \n\, like:
+Manage the space-separated list of debuginfod server URLs that GDB will\n\
+query when missing debuginfo, executables or source files.\n\
+The default value is copied from the DEBUGINFOD_URLS environment variable."),
Approved-By: Eli Zaretskii <eliz@gnu.org>
I recently came across a case where a compiler would emit a CU with an
empty name. In such case, the attribute object constructed by GDB will
return nullptr when as_string is called. One place is not checking for
this possibility. As a result, loading such binary results in a GDB
crash:
$ gdb -q a.out
Reading symbols from a.out...
Fatal signal: Segmentation fault
----- Backtrace -----
[...]
0x742f4dd8afab __strcmp_avx2
../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
0x58593704a0bc prepare_one_comp_unit
../../gdb/dwarf2/read.c:21842
0x585937053fd9 process_psymtab_comp_unit
../../gdb/dwarf2/read.c:4633
0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
../../gdb/dwarf2/read.c:4943
[...]
---------------------
A fatal error internal to GDB has been detected, further
debugging is not possible. GDB will now terminate.
This is a bug, please report it. For instructions, see:
<https://www.gnu.org/software/gdb/bugs/>.
Segmentation fault (core dumped)
This seems to be a regression introduced by the following commit:
commit 00105aa1c4
Date: Tue Sep 24 10:24:22 2024 +0200
[gdb/symtab] Don't expand non-Ada CUs for info exceptions
This patch fixes this issue by checking if attr->as_string returns
nullptr.
Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
gdb::hash_enum is a workaround for a small oversight in C++11:
std::hash was not defined for enumeration types. This was rectified
in C++14 and so we can remove the local workaround.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
When compiling dw2-multiple-debug-info.c using -gdwarf-5
-fdebug-types-section, we end with two .debug_info sections in the object
file:
...
$ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \
-gdwarf-5 \
-fdebug-types-section
$ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info
[10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8
[12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8
...
One of them contains the CU for dw2-multiple-debug-info.c, the other contains
the TU for the type of variable a.
When trying to print the type of variable a, we get:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
'a' has unknown type; cast it to its declared type
...
because the TU hasn't been read.
Fix this by adding support for reading multiple .debug_info sections, similar
to how that is done for multiple .debug_types sections, getting us instead:
...
$ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a"
type = class sp1::A {
...
}
...
Tested on x86_64-linux.
PR symtab/32223
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223
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
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.
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
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
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.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>
[ 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
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>
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
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
This fixes a couple of comments in dwarf2/cooked-index.h.
The comment by cooked_index_entry::canonical mentions C++, but this
field can also be different from 'name' in other situations. Rather
than enumerate the cases here (which doesn't seem important), make the
text a little less specific.
Also, cooked_index_entry::write_scope doesn't document its "for_main"
parameter -- and it is misnamed in the prototype as well.
Reviewed-By: Tom de Vries <tdevries@suse.de>
This changes cooked_index_shard::handle_gnat_encoded_entry to modify
the incoming entry itself, and to return void rather than a new name.
this simplifies the caller a little, which is convenient for a
different series I am working on.
Approved-By: Tom de Vries <tdevries@suse.de>
DW_TAG_padding isn't a real tag -- it doesn't appear in the DWARF
standard, only in include/dwarf2.def as a placeholder. So, remove it
from dwarf2/tag.h:tag_is_type.
Reviewed-By: Tom de Vries <tdevries@suse.de>
This commit changes how GDB processes command arguments for the
following commands:
compile file
maint print c-tdesc
save gdb-index
After this commit these commands will now expect their single filename
argument to be (optionally) quoted if it contains any special
characters (e.g. whit space or quotes).
If the filename does not contain any special characters then nothing
changes. As an example:
(gdb) save gdb-index /path/to/some/directory/
will work before and after this patch. However, if the directory
name contains a white space then before this patch a user would write:
(gdb) save gdb-index /path/to some/directory/
But this will now fail as GDB will consider this as two arguments,
'/path/to' and 'some/directory/'. To pass this single directory name
a user must now do one of these:
(gdb) save gdb-index "/path/to some/directory/"
(gdb) save gdb-index '/path/to some/directory/'
(gdb) save gdb-index /path/to\ some/directory/
This brings these commands into line with commands like 'file' and
'symbol-file', which have supported quoted filenames for a while.
The motivation for this change is to make handling of filename
arguments consistent throughout GDB. We can't move to all commands
taking non-quoted filenames as the non-quoted style only allows for a
single argument. Additionally, the non-quoted style doesn't allow for
filenames that end in white space (though this is probably pretty
rare). So, if we want to have consistency the only choice is to move
towards supporting quote filenames.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Following on from the previous commit, this commit marks the old
unquoted filename completion related functions as deprecated.
The aim of doing this is to make it more obvious to someone adding a
new command that they should not be using the older unquoted style
filename argument handling.
I split this change from the previous to make for an easier review.
This commit touches more files, but is _just_ function renaming.
Check out gdb/completer.{c,h} for what has been renamed. All the
other files have just been updated to use the new names.
There should be no user visible changes after this commit.
I noticed that the comments for class parent_map aren't very clear.
This patch attempts to fix this, and also clarifies a point on
parent_map_map::add_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Cleanup includes in dwarf2/*.
1. Add the necessary includes so that clangd reports no errors when
opening header files. This ensures that header files include what
they use.
2. Remove all includes reported as unused by clangd (except
gdb-safe-ctype.h, which I think does some magic that affects what
follows).
Built-tested --enable-threading at "yes" and "no", since there are some
portions of code gated by `#ifdef CXX_STD_THREAD`.
Change-Id: I21debffcd7c2caf90f08e1e0fbba3ce30422d042
Approved-By: Tom Tromey <tom@tromey.com>
I noticed that process_enumeration_scope checks the result of
dwarf2_name. However, this isn't needed, because new_symbol does the
same check. This patch removes the unnecessary code.
Reviewed-by: Keith Seitz <keiths@redhat.com>
It was suggested here [1] that the canonical prefix for dwarf errors
should not be "Dwarf Error: ", given that the canonical spelling is DWARF
instead of Dwarf.
Fix this by using "DWARF Error: " instead.
Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single
location.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
Result of:
...
$ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/*
...
and manually fixing indentation.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Add a new header file gdb/dwarf2/error.h, containing macros:
- DWARF_ERROR, and
- DWARF_ERROR_PREFIX.
The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch.
No functional changes.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
In gdb/dwarf2/read.c, I found a few strings "in module %s":
...
$ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '['
"DIE at %s in module %s"),
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
error (_("Dwarf Error: DIE at %s referenced in module %s "
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
...
that are not using the commonly used "[in module %s]" notation. Fix these.
In one case, the string was also used in the middle rather than at the end of
the message, so fix that as well.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Commit a8caed5d7f handled the tombstone
value -1 used by lld (https://reviews.llvm.org/D81784). The
referenced lld commit also uses the tombstone value -2 for
pre-DWARF-v5
(e618ccbf43).
If not handled, -2 breaks the pc step range calculation and triggers
the assertion:
gdb/infrun.c:2794: internal-error: resume_1: Assertion
`pc_in_thread_step_range (pc, tp)' failed.
This commit adds -2 tombstone value and handles it in the same way as -1.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727
Approved-By: Tom Tromey <tom@tromey.com>
A corrupt debuginfo file can result in a null abbrev_info pointer
being passed to cooked_indexer::scan_attributes. This pointer
is set to nullptr by peek_die_abbrev when an abbrev of 0 is found.
There is no check for whether the abbrev pointer is null and
SIGSEGV occurs when attempting to dereference the pointer.
An abbrev of 0 normally indicates that the corresponding DIE is a
null entry, but scan_attributes expects a non-null DIE.
Fix this by throwing an error in cooked_indexer::scan_attributes
when peek_die_abbrev returns a nullptr in order to avoid
scan_attributes calling itself with a null abbrev.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478
Co-authored-by: Tom de Vries <tdevries@suse.de>
Approved-By: Tom Tromey <tom@tromey.com>
With the test-case included in this patch, we run into:
...
$ gdb -q -batch $exec
Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
[in module $exec]
...
The debug info consists of two CUs:
...
Compilation Unit @ offset 0xb2:
Length: 0x25 (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: <0xe8>
<1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
<d5> DW_AT_name : main
<1><da>: Abbrev Number: 0
Compilation Unit @ offset 0xdb:
Length: 0xf (32-bit)
Version: 4
Abbrev Offset: 0x86
Pointer Size: 8
<0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
<e7> DW_AT_language : 2 (non-ANSI C)
<1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
<e9> DW_AT_specification: <0xd4>
<1><ed>: Abbrev Number: 0
...
where:
- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
- DIE 0xd4 back in CU@0xb2.
The dwarf error is caused by this bit of code in
cooked_indexer::ensure_cu_exists:
...
if (per_cu == m_per_cu)
return reader;
...
The dwarf error happens as follows:
- a cutu_reader A is created for CU@0xb2
- using cutu_reader A, the cooked index reader starts indexing dies, with
m_per_cu set to CU@0xb2
- while indexing it scans the attributes of DIE 0xbf and encounters the
inter-CU reference to DIE 0xe8
- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
CU@0xdb and returns it
- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
encounters the inter-CU reference to DIE 0xd4
- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
and cutu_reader B is returned
- using cutu_reader B, it continues scanning attributes of DIE 0xd4
- this goes wrong because:
- the attributes of the DIE are encoded using the abbreviation table at
offset 0x6c, while
- the decoding is done using cutu_reader B which uses the abbreviation table
at offset 0x86.
Fix this by removing the problematic if clause.
Since cutu_reader A is not preserved in m_index_storage,
cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving
the cutu_reader A as well in m_index_storage.
Tested on x86_64-linux and aarch64-linux.
PR symtab/32081
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081
Approved-By: Tom Tromey <tom@tromey.com>
Reported-By: Andreas Schwab <schwab@linux-m68k.org>
dwarf2/read.c has this code:
else if (elf_section_data (sectp)->this_hdr.sh_size
> bfd_get_file_size (abfd))
This assumes that the BFD is an ELF, which is an invalid assumption.
A user noticed that this can sometimes cause a crash.
This patch fixes the problem by changing this code to use
bfd_section_size_insane.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104
Reviewed-By: Tom de Vries <tdevries@suse.de>
Reviewed-by: Keith Seitz <keiths@redhat.com>
This patch simplifies typename_concat, changing the return type and
removing the obstack allocation code. The latter is possible because
the only caller using this mode uses the name when creating a new
type, and 'new_type' copies the string to the appropriate obstack
anyway. It also changes typename_concat to use 'concat'. This change
lets us remove a mildly fragile macro as well.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Make the current_program_space reference bubble up one level.
Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
>From what I can see, lookup_minimal_symbol doesn't have any dependencies
on the global current state other than the single reference to
current_program_space. Add a program_space parameter and make that
current_program_space reference bubble up one level.
Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Most calls to lookup_minimal_symbol don't pass a value for sfile and
objf. Make these parameters optional (have a default value of
nullptr). And since passing a value to `objf` is much more common than
passing a value to `sfile`, swap the order so `objf` comes first, to
avoid having to pass a nullptr value to `sfile` when wanting to pass a
value to `objf`.
Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
This is a simple find / replace from "struct bound_minimal_symbol" to
"bound_minimal_symbol", to make things shorter and more consisten
througout. In some cases, move variable declarations where first used.
Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849
Reviewed-by: Keith Seitz <keiths@redhat.com>
Approved-By: Andrew Burgess <aburgess@redhat.com>
Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the
.debug_macro section.
For one malformed macro definition, I get two identical complaints:
...
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
During symbol reading: macro debug info contains a malformed macro definition:^M
`M1_11_MALFORMED(ARG'^M
...
Fix this by bailing out after the first one.
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Use std::vector<std::string> when defining macros, to avoid the manual
memory management.
With the use of std::vector, the separate `int argc` parameter is no
longer needed, we can use the size of the vector instead. However, for
some functions, this parameter had a dual function. For object-like
macros, it was interpreted as a `macro_special_kind` enum. For these
functions, remove `argc`, but add a new `special_kind` parameter.
Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5
Approved-By: Tom de Vries <tdevries@suse.de>
C++ 11 has a built-in attribute for this, no need to use a compat macro.
Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875
Reviewed-by: Lancelot Six <lancelot.six@amd.com>
Add two overloads of gdb_abspath, one which takes std::string and one
which takes gdb::unique_xmalloc_ptr<char>, then make use of these
overloads throughout GDB and gdbserver.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
In case a DIE contains a linkage name which cannot be demangled and
a source language name (DW_AT_NAME) exists then we want to display this name
instead of the non-demangeable linkage name.
dwarf2_physname returns the linkage name in case the linkage name
cannot be demangled. Before this patch we always set the returned physname
as demangled name. This patch changes this by comparing the value
of physname with the linkage name. Now after this change in case it is equals
to the linkage name and if DW_AT_NAME exists then this is set as the demangled
name otherwise like before still linkage name is used.
For the reproducer, using the test source file added in this change:
"gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c"
Here is an example of the DWARF where wrong linkage name is emitted by the
compiler for the "func_demangled_test" function:
subprogram {
{MACRO_AT_range {func_demangled_test}}
{linkage_name "_FUNC_WRONG_MANGLED__"}
{name "func_demangled_test"}
{external 1 flag}
}
subprogram {
{MACRO_AT_range {main}}
{external 1 flag}
{name main}
{main_subprogram 1 flag}
}
Before this change for a function having both DIEs DW_AT_name and
DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace
command shows following:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
(gdb) backtrace
\#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ ()
\#1 0x000055555555514a in main ()
After the change now GDB shows the name emitted by DW_AT_NAME:
(gdb) b func_demangled_test
(gdb) r
Breakpoint 1, 0x0000555555555131 in func_demangled_test ()
(gdb) backtrace
\#0 0x0000555555555131 in func_demangled_test ()
\#1 0x000055555555514a in main ()
A new test is added to verify this change.
Approved-By: Tom Tromey <tom@tromey.com>
The call site hash table is the last hash table using obstack
allocation. In one large (non-public) test case, these hash tables
take a substiantial amount of memory. Some of this memory is wasted
-- whenever the hash table is resized, the old table is not freed.
This patch fixes the problem by changing this hash table to be
heap-allocated. This means that resizing will no longer "leak"
memory.
