| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
Fix the following common misspellings:
...
accidently -> accidentally
additonal -> additional
addresing -> addressing
adress -> address
agaisnt -> against
albiet -> albeit
arbitary -> arbitrary
artifical -> artificial
auxillary -> auxiliary
auxilliary -> auxiliary
bcak -> back
begining -> beginning
cannonical -> canonical
compatiblity -> compatibility
completetion -> completion
diferent -> different
emited -> emitted
emiting -> emitting
emmitted -> emitted
everytime -> every time
excercise -> exercise
existance -> existence
fucntion -> function
funtion -> function
guarentee -> guarantee
htis -> this
immediatly -> immediately
layed -> laid
noone -> no one
occurances -> occurrences
occured -> occurred
originaly -> originally
preceeded -> preceded
preceeds -> precedes
propogate -> propagate
publically -> publicly
refering -> referring
substract -> subtract
substracting -> subtracting
substraction -> subtraction
taht -> that
targetting -> targeting
teh -> the
thier -> their
thru -> through
transfered -> transferred
transfering -> transferring
upto -> up to
vincinity -> vicinity
whcih -> which
whereever -> wherever
wierd -> weird
withing -> within
writen -> written
wtih -> with
doesnt -> doesn't
...
Tested on x86_64-linux.
|
|
[ 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 d2f67711730
("Fix 'catch exception' with -flto").
Now that we have lang_matcher available, also use it to limit name splitting
styles and symbol matchers to those applicable to the matched languages.
Without this patch we have (with a gdb build with -O0):
...
$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
real 0m1.866s
user 0m2.089s
sys 0m0.120s
...
and with this patch we have:
...
$ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null
real 0m0.469s
user 0m0.777s
sys 0m0.051s
...
Or, to put it in terms of number of CUs, we have 1853 CUs:
...
$ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \
-ex start \
-ex "maint info symtabs" \
| grep -c " name "
1853
...
Without this patch, we have:
...
$ gdb -q -batch outputs/gdb.ada/info_exc/foo \
-ex start \
-ex "info exceptions" \
-ex "maint info symtabs" \
| grep -c " name "
1393
...
so ~75% of the CUs is expanded, and with this patch we have:
...
$ gdb <same-as-above>
20
...
so ~1% of the CUs is expanded.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
PR symtab/32182
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182
|
|
scanner"
After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds
this debug info:
...
<1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type)
<120> DW_AT_specification: <0x130>
<2><124>: Abbrev Number: 4 (DW_TAG_enumerator)
<125> DW_AT_name : val1
<12a> DW_AT_const_value : 1
<2><12b>: Abbrev Number: 0
<1><12c>: Abbrev Number: 5 (DW_TAG_namespace)
<12d> DW_AT_name : ns
<2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type)
<131> DW_AT_name : e
<133> DW_AT_type : <0x118>
<137> DW_AT_declaration : 1
...
I run into an assertion failure:
...
(gdb) file enum-type^M
Reading symbols from enum-type...^M
cooked-index.h:214: internal-error: get_parent: \
Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M
...
This was reported in PR32160 comment 1.
This is a regression since commit 4e417d7bb1c ("Change handling of
DW_TAG_enumeration_type in DWARF scanner").
Fix this by reverting the commit.
[ Also drop the kfails for PR31900 and PR32158, which are regressions by that
same commit. ]
That allows us to look at the output of "maint print objfiles", and for val1
we get an entry without parent:
...
[27] ((cooked_index_entry *) 0x7fbbb4002ef0)
name: val1
canonical: val1
qualified: val1
DWARF tag: DW_TAG_enumerator
flags: 0x0 []
DIE offset: 0x124
parent: ((cooked_index_entry *) 0)
...
which is incorrect, as noted in that same comment, but an improvement over the
assertion failure, and I don't think that ever worked. This is to be
addressed in a follow-up patch.
Reverting the commit begs the question: what was it trying to fix in the first
place, and do we need a different fix? I've investigated this and filed
PR32160 to track this.
My guess is that the commit was based on a misunderstand of what we track
in cooked_indexer::m_die_range_map.
Each DIE has two types of parent DIEs:
- a DIE that is the parent as indicated by the tree structure in which DIEs
occur, and
- a DIE that represent the parent scope.
In most cases, these two are the same, but some times they're not.
The debug info above demonstrates such a case. The DIE at 0x11f:
- has a tree-parent: the DIE representing the CU, and
- has a scope-parent: DIE 0x12c representing namespace ns.
In cooked_indexer::m_die_range_map, we track scope-parents, and the commit
tried to add a tree-parent instead.
So, I don't think we need a different fix, and propose we backport the reversal
for gdb 15.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160
|
|
Approved-By: Tom Tromey <tom@tromey.com>
|
|
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 a8caed5d7faa639a1e6769eba551d15d8ddd9510 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
(https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7).
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>
|
|
cooked_indexer::ensure_cu_exists
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>
|
|
In parse_macro_definition, there's a loop:
...
for (p = body; *p; p++)
if (*p == ' ' || *p == '(')
break;
...
whose post-condition is:
...
gdb_assert (*p == ' ' || *p == '(' || *p == '\0');
...
Consequently, in the following:
...
if (*p == ' ' || *p == '\0')
<BODY1>
else if (*p == '(')
<BODY2>
else
<BODY3>
...
BODY3 is dead code.
Remove it, and get rid of unnecessary indentation by using an early-exit:
....
if (*p == ' ' || *p == '\0')
{
<BODY1>
return;
}
gdb_assert (*p == '(');
<BODY2>
...
Tested on aarch64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A few spots in gdb were using htab_traverse. IMO this is almost never
useful and htab_traverse_noresize should be preferred.
|
|
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.
|
|
The CU dependency hash table is obstack-allocated, but there's no need
to do this.
|
|
The DIE hash table is currently allocated on an obstack. There's no
need to do this, and I think it's better to simply heap-allocate the
hash table.
This patch implements this. I also removed store_in_ref_table as
well, inlining it into its sole caller, as I think this is clearer.
|
|
When running test-case gdb.base/complex-parts.exp on arm-linux, I get:
...
(gdb) p $_cimag (z3)^M
$6 = 6.5^M
(gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3)
ptype $^M
type = double^M
(gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $
...
Given that z3 is a complex long double, the test-case expects the type of the
imaginary part of z3 to be long double, but it's double instead.
This is due to the fact that the dwarf info doesn't specify an explicit target
type:
...
<5b> DW_AT_name : z3
<60> DW_AT_type : <0xa4>
...
<1><a4>: Abbrev Number: 2 (DW_TAG_base_type)
<a5> DW_AT_byte_size : 16
<a6> DW_AT_encoding : 3 (complex float)
<a7> DW_AT_name : complex long double
...
and consequently we're guessing in dwarf2_init_complex_target_type based on
the size:
...
case 64:
tt = builtin_type (gdbarch)->builtin_double;
break;
case 96: /* The x86-32 ABI specifies 96-bit long double. */
case 128:
tt = builtin_type (gdbarch)->builtin_long_double;
break;
...
For arm-linux, complex long double is 16 bytes, so the target type is assumed
to be 8 bytes, which is handled by the "case 64", which gets us double
instead of long double.
Fix this by searching for "long" in the name_hint parameter, and using long
double instead.
Note that base types in dwarf are not allowed to contain references to other
types, and the complex types are base types, so the missing explicit target
type is standard-conformant.
A gcc PR was filed to add this as a dwarf extension (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ).
Tested on arm-linux.
|
|
dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader,
so this field can be moved to mapped_gdb_index instead. Then,
cooked_index_functions::find_per_cu can be removed in favor of a
method on the index object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
|
|
Unfortunately the background DWARF reading series introduced a number
of races, as repored by thread sanitizer. This patch changes gdb to
disable this feature for the time being -- in particular for the gdb
15 release.
I've filed a bug and linked all the known races to it. Once those are
fixed we can re-enable this feature by default.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
|
|
|
|
It will be used for all segments in a qualified name,
not only the last one.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
|
|
The added check fixes the case when an unqualified lookup
name without template arguments causes expansion of many CUs
which contain the name with template arguments.
This is similar to what dw2_expand_symtabs_matching_symbol does
before expanding the CU.
In the referenced issue the lookup name was wxObjectDataPtr and many
CUs had names like wxObjectDataPtr<wxBitmapBundleImpl>. This caused
their expansion and the lookup took around a minute. The added check
helps to avoid the expansion and makes the symbol lookup to return in
a second or so.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520
|
|
If threads are disabled, either by --disable-threading explicitely, or by
missing std::thread support, you get the following ASAN error when
loading symbols:
==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68
READ of size 1 at 0x614000002128 thread T0
#0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163
#1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601
#2 0x1705e39 in std::function<void ()>::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690
#3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38
0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8)
freed by thread T0 here:
#0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177
#1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689
#2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657
#3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300
It's happening because cooked_index_worker::wait always returns true in
this case, which tells cooked_index::wait it can delete the m_state
cooked_index_worker member, but cooked_index_worker::write_to_cache tries
to access it immediately afterwards.
Fixed by making cooked_index_worker::wait only return true if desired_state
is CACHE_DONE, same as if threading was enabled, so m_state will not be
prematurely deleted.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694
Approved-By: Tom Tromey <tom@tromey.com>
|
|
All the calls to dwarf2_per_objfile::adjust have been removed, so we
can remove this function entirely.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261
|
|
Currently, read_attribute_value calls dwarf2_per_objfile::adjust on
any address. This seems wrong, because the address may not even be in
the text section.
Luckily, this call is also not needed, because read_func_scope calls
'relocate', which does the same work.
|
