This introduces dwarf_scanner_base, a base class for all the index
readers in the DWARF code. Then, it changes both mapped_index_base
and cooked_index_vector to derive from this new base class.
This introduces readnow_functions, a new subclass of
dwarf2_base_index_functions, and changes the DWARF reader to use it.
This lets us drop the "index is NULL" hack from the gdb index code.
The dwarf2_debug_names_index code treats a NULL debug_names_table as
if it were from OBJF_READNOW. However, this trick is only done for
gdb_index, never for debug_names -- see dwarf2_initialize_objfile.
This changes the mapped index classes to create the
quick_symbol_functions objects. This is a step toward having a more
abstract interface to mapped indices.
When running the internal AdaCore test suite against the new DWARF
indexer, I found one regression on RISC-V. The test in question uses
--gc-sections, and winds up with an entry in the middle of a
.debug_aranges that has both address and length of 0. In this
scenario, gdb assumes the entries are terminated and then proceeds to
reject the section because it reads a subsequent entry as if it were a
header.
It seems to me that, because each header describes the size of each
.debug_aranges CU, it's better to simply ignore 0,0 entries and simply
read to the end. That is what this patch does.
I've patched an existing test to provide a regression test for this.
Change subfile::name to be a string, for easier memory management.
Change buildsym_compunit::m_comp_dir as well, since we move one in to
the other at some point in patch_subfile_names, so it's easier to do
both at the same time. There are various NULL checks for both fields
currently, replace them with empty checks, I think it ends up
equivalent.
I can't test the change in xcoffread.c, it's best-effort.
Change-Id: I62b5fb08b2089e096768a090627ac7617e90a016
When building with -std=c++11, I get:
CXX dwarf2/read.o
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c: In function ‘void dwarf2_build_psymtabs_hard(dwarf2_per_objfile*)’:
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:7130:23: error: expected type-specifier before ‘typeof’
7130 | using iter_type = typeof (per_bfd->all_comp_units.begin ());
| ^~~~~~
This is because typeof is a GNU extension. Use C++'s decltype keyword
instead.
Change-Id: Ieca2e8d25e50f71dc6c615a405a972a54de3ef14
Now that the psymtab reader has been removed, the
dwarf2_per_cu_data::v union is no longer needed. Instead, we can
simply move the members from dwarf2_per_cu_quick_data into
dwarf2_per_cu_data and remove the "quick" object entirely.
This patch finally enables the new indexer. It is left until this
point in the series to avoid any regressions; in particular, it has to
come after the changes to the DWARF index writer to avoid this
problem.
However, if you experiment with the series, this patch can be moved
anywhere from the patch to wire in the new reader to this point.
Moving this patch around is how I got separate numbers for the
parallelization and background finalization patches.
In the ongoing performance example, this reduces the time from the
baseline of 1.598869 to 0.903534.
This parallelizes the new DWARF indexer. The indexer's storage was
designed so that each storage object and each indexer is fully
independent. This setup makes it simple to scan different CUs
independently.
This patch creates a new cooked index storage object per thread, and
then scans a subset of all the CUs in each such thread, using gdb's
existing thread pool.
In the ongoing "gdb gdb" example, this patch reduces the wall time
down to 0.668923, from 0.903534. (Note that the 0.903534 is the time
for the new index -- that is, when the "enable the new index" patch is
rebased to before this one. However, in the final series, that patch
appears toward the end. Hopefully this isn't too confusing.)
Because BFD is not thread-safe, we need to be sure that any section
data that is needed is read before trying to do any DWARF indexing in
the background.
This patch takes a simple approach to this -- it pre-reads the
"info"-related sections. This is done for the main file, but also any
auxiliary files as well, such as the DWO file.
This patch could be perhaps enhanced by removing some now-redundant
calls to dwarf2_section_info::read.
This wires the new DWARF indexer into the existing reader code. That
is, this patch makes the modification necessary to enable the new
indexer. It is not actually enabled by this patch -- that will be
done later.
I did a bit of performance testing for this patch and a few others. I
copied my built gdb to /tmp, so that each test would be done on the
same executable. Then, each time, I did:
$ ./gdb -nx
(gdb) maint time 1
(gdb) file /tmp/gdb
This patch is the baseline and on one machine came in at 1.598869 wall
time.
This implements quick_symbol_functions for the cooked DWARF index.
This is the code that interfaces between the new index and the rest of
gdb. Cooked indexes still aren't created by anything.
For the most part this is straightforward. It shares some concepts
with the existing DWARF indices. However, because names are stored
pre-split in the cooked index, name lookup here is necessarily
different; see expand_symtabs_matching for the gory details.
This patch adds the code to index DWARF. This is just the scanner; it
reads the DWARF and constructs the index, but nothing calls it yet.
The indexer is split into two parts: a storage object and an indexer
object. This is done to support the parallelization of this code -- a
future patch will create a single storage object per thread.
This changes the file_and_directory object to be able to compute and
cache the "fullname" in the same way that is done by other code, like
the psymtab reader.
The new DWARF scanner needs to save the entire cutu_reader object, not
just parts of it. In order to make this possible, this patch
refactors build_type_psymtabs_reader. This change is done separately
because it is easy to review in isolation and it helps make the later
patches smaller.
This changes dwarf2_get_pc_bounds so that it does not directly access
a psymtab or psymtabs_addrmap. Instead, both the addrmap and the
desired payload are passed as parameters. This makes it suitable to
be used by the new indexer.
This adds a new member to dwarf2_per_cu_data that indicates whether
addresses have been seen for this CU. This is then set by the
.debug_aranges reader. The idea here is to detect when a CU does not
have address information, so that the new indexer will know to do
extra scanning in that case.
Tom de Vries found a failure that we tracked down to a latent bug in
read_addrmap_from_aranges (previously create_addrmap_from_aranges).
The bug is that this code can erroneously reject .debug_aranges when
dwz is in use, due to CUs at duplicate offsets. Because aranges can't
refer to a CU coming from the dwz file, the fix is to simply skip such
CUs in the loop.
Add support for DW_LNS_set_prologue_end when building line-tables. This
attribute can be set by the compiler to indicate that an instruction is
an adequate place to set a breakpoint just after the prologue of a
function.
The compiler might set multiple prologue_end, but considering how
current skip_prologue_using_sal works, this commit modifies it to accept
the first instruction with this marker (if any) to be the place where a
breakpoint should be placed to be at the end of the prologue.
The need for this support came from a problematic usecase generated by
hipcc (i.e. clang). The problem is as follows: There's a function
(lets call it foo) which covers PC from 0xa800 to 0xa950. The body of
foo begins with a call to an inlined function, covering from 0xa800 to
0xa94c. The issue is that when placing a breakpoint at 'foo', GDB
inserts the breakpoint at 0xa818. The 0x18 offset is what GDB thinks is
foo's first address past the prologue.
Later, when hitting the breakpoint, GDB reports the stop within the
inlined function because the PC falls in its range while the user
expects to stop in FOO.
Looking at the line-table for this location, we have:
INDEX LINE ADDRESS IS-STMT
[...]
14 293 0x000000000000a66c Y
15 END 0x000000000000a6e0 Y
16 287 0x000000000000a800 Y
17 END 0x000000000000a818 Y
18 287 0x000000000000a824 Y
[...]
For comparison, let's look at llvm-dwarfdump's output for this CU:
Address Line Column File ISA Discriminator Flags
------------------ ------ ------ ------ --- ------------- -------------
[...]
0x000000000000a66c 293 12 2 0 0 is_stmt
0x000000000000a6e0 96 43 82 0 0 is_stmt
0x000000000000a6f8 102 18 82 0 0 is_stmt
0x000000000000a70c 102 24 82 0 0
0x000000000000a710 102 18 82 0 0
0x000000000000a72c 101 16 82 0 0 is_stmt
0x000000000000a73c 2915 50 83 0 0 is_stmt
0x000000000000a74c 110 1 1 0 0 is_stmt
0x000000000000a750 110 1 1 0 0 is_stmt end_sequence
0x000000000000a800 107 0 1 0 0 is_stmt
0x000000000000a800 287 12 2 0 0 is_stmt prologue_end
0x000000000000a818 114 59 81 0 0 is_stmt
0x000000000000a824 287 12 2 0 0 is_stmt
0x000000000000a828 100 58 82 0 0 is_stmt
[...]
The main difference we are interested in here is that llvm-dwarfdump's
output tells us that 0xa800 is an adequate place to place a breakpoint
past a function prologue. Since we know that foo covers from 0xa800 to
0xa94c, 0xa800 is the address at which the breakpoint should be placed
if the user wants to break in foo.
This commit proposes to add support for the prologue_end flag in the
line-program processing.
The processing of this prologue_end flag is made in skip_prologue_sal,
before it calls gdbarch_skip_prologue_noexcept. The intent is that if
the compiler gave information on where the prologue ends, we should use
this information and not try to rely on architecture dependent logic to
guess it.
The testsuite have been executed using this patch on GNU/Linux x86_64.
Testcases have been compiled with both gcc/g++ (verison 9.4.0) and
clang/clang++ (version 10.0.0) since at the time of writing GCC does not
set the prologue_end marker. Tests done with GCC 11.2.0 (not over the
entire testsuite) show that it does not emit this flag either.
No regression have been observed with GCC or Clang. Note that when
using Clang, this patch fixes a failure in
gdb.opt/inline-small-func.exp.
Change-Id: I720449a8a9b2e1fb45b54c6095d3b1e9da9152f8
Currently when recording a line entry (with
buildsym_compunit::record_line), a boolean argument argument is used to
indicate that the is_stmt flag should be set for this particular record.
As a later commit will add support for new flags, instead of adding a
parameter to record_line for each possible flag, transform the current
is_stmt parameter into a enum flag. This flags parameter will allow
greater flexibility in future commits.
This enum flags type is not propagated into the linetable_entry type as
this would require a lot of changes across the codebase for no practical
gain (it currently uses a bitfield where each interesting flag only
occupy 1 bit in the structure).
Tested on x86_64-linux, no regression observed.
Change-Id: I5d061fa67bdb34918742505ff983d37453839d6a
It's a bit confusing because we have both "compunit_symtab" and "symtab"
types, and many methods and functions containing "start_symtab" or
"end_symtab", which actually deal with compunit_symtabs. I believe this
comes from the time before compunit_symtab was introduced, where
symtab did the job of both.
Rename everything I found containing start_symtab or end_symtab to use
start_compunit_symtab or end_compunit_symtab.
Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
This patch adds a new dynamic property DYN_PROP_RANK, this property is
read from the DW_AT_rank attribute and stored within the type just
like other dynamic properties.
As arrays with dynamic ranks make use of a single
DW_TAG_generic_subrange to represent all ranks of the array, support
for this tag has been added to dwarf2/read.c.
The final piece of this puzzle is to add support in gdbtypes.c so that
we can resolve an array type with dynamic rank. To do this the
existing resolve_dynamic_array_or_string function is split into two,
there's a new resolve_dynamic_array_or_string_1 core that is
responsible for resolving each rank of the array, while the now outer
resolve_dynamic_array_or_string is responsible for figuring out the
array rank (which might require resolving a dynamic property) and then
calling the inner core.
The resolve_dynamic_range function now takes a rank, which is passed
on to the dwarf expression evaluator. This rank will only be used in
the case where the array itself has dynamic rank, but we now pass the
rank in all cases, this should be harmless if the rank is not needed.
The only small nit is that resolve_dynamic_type_internal actually
handles resolving dynamic ranges itself, which now obviously requires
us to pass a rank value. But what rank value to use? In the end I
just passed '1' through here as a sane default, my thinking is that if
we are in resolve_dynamic_type_internal to resolve a range, then the
range isn't part of an array with dynamic rank, and so the range
should actually be using the rank value at all.
An alternative approach would be to make the rank value a
gdb::optional, however, this ends up adding a bunch of complexity to
the code (e.g. having to conditionally build the array to pass to
dwarf2_evaluate_property, and handling the 'rank - 1' in
resolve_dynamic_array_or_string_1) so I haven't done that, but could,
if people think that would be a better approach.
Finally, support for assumed rank arrays was only fixed very recently
in gcc, so you'll need the latest gcc in order to run the tests for
this.
Here's an example test program:
PROGRAM arank
REAL :: a1(10)
CALL sub1(a1)
CONTAINS
SUBROUTINE sub1(a)
REAL :: a(..)
PRINT *, RANK(a)
END SUBROUTINE sub1
END PROGRAM arank
Compiler Version:
gcc (GCC) 12.0.0 20211122 (experimental)
Compilation command:
gfortran assumedrank.f90 -gdwarf-5 -o assumedrank
Without Patch:
gdb -q assumedrank
Reading symbols from assumedrank...
(gdb) break sub1
Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
(gdb) run
Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787
/bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10
10 PRINT *, RANK(a)
(gdb) print RANK(a)
'a' has unknown type; cast it to its declared type
With patch:
gdb -q assumedrank
Reading symbols from assumedrank...
(gdb) break sub1
Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10.
(gdb) run
Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank
Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10
10 PRINT *, RANK(a)
(gdb) print RANK(a)
$1 = 1
(gdb) ptype a
type = real(kind=4) (10)
(gdb)
Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Now that filtered and unfiltered output can be treated identically, we
can unify the printf family of functions. This is done under the name
"gdb_printf". Most of this patch was written by script.
Now that filtered and unfiltered output can be treated identically, we
can unify the puts family of functions. This is done under the name
"gdb_puts". Most of this patch was written by script.
A large customer program has a function that is partitioned into hot
and cold parts. A variable in a callee of this function is described
using DW_OP_GNU_entry_value, but gdb gets confused when trying to find
the caller. I tracked this down to dwarf2_get_pc_bounds interpreting
the function's changes so that the returned low PC is the "wrong"
function.
Intead, when processing DW_TAG_call_site, the low PC of each range in
DW_AT_ranges should be preserved in the call_site_target. This fixes
the variable lookup in the test case I have.
I didn't write a standalone test for this as it seemed excessively
complicated.
Gfortran supports namelists (a Fortran feature); it emits
DW_TAG_namelist and DW_TAG_namelist_item dies. But gdb does not
process these dies and does not support 'print' or 'ptype' commands on
namelist variables.
An attempt to print namelist variables results in gdb bailing out with
the error message as shown below.
(gdb) print nml
No symbol "nml" in current context.
This commit is to make the print and ptype commands work for namelist
variables and its items. Sample output of these commands is shared
below, with fixed gdb.
(gdb) ptype nml
type = Type nml
integer(kind=4) :: a
integer(kind=4) :: b
End Type nml
(gdb) print nml
$1 = ( a = 10, b = 20 )
Add a getter and a setter for a symbol's line. Remove the corresponding macro
and adjust all callers.
Change-Id: I229f2b8fcf938c07975f641361313a8761fad9a5
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
Add a getter and a setter for whether a symbol is inlined. Remove the
corresponding macro and adjust all callers.
Change-Id: I934468da3b5a32dd6b161a6f252a6b1b94737279
Add a getter and a setter for whether a symbol is an argument. Remove
the corresponding macro and adjust all callers.
Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
Add a getter and a setter for a symbol's aclass index. Remove the
corresponding macro and adjust all callers.
Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
Add a getter and a setter for a symtab's language. Remove the
corresponding macro and adjust all callers.
Change-Id: I9f4d840b11c19f80f39bac1bce020fdd1739e11f
Add a getter and a setter for a compunit_symtab's epilogue unwind valid flag.
Remove the corresponding macro and adjust all callers.
Change-Id: If3b68629d987767da9be7041a95d96dc34367a9a
Add a getter and a setter for a compunit_symtab's locations valid flag.
Remove the corresponding macro and adjust all callers.
Change-Id: I3e3cfba926ce62993d5b61814331bb3244afad01
Add a getter and a setter for a compunit_symtab's blockvector. Remove
the corresponding macro and adjust all callers.
Change-Id: I99484c6619dcbbea7c5d89c72aa660316ca62f64
Add a getter and a setter for a compunit_symtab's dirname. Remove the
corresponding macro and adjust all callers.
Change-Id: If2f39b295fd26822586485e04a8b8b5aa5cc9b2e
I think that most remaining uses of COMPUNIT_FILETABS intend to get the
primary filetab of the compunit_symtab specifically (and not to iterate
over all filetabs, for example, those cases would use compunit_filetabs,
which has been converted to compunit_symtab::filetabs), so replace mosts
uses with compunit_symtab::primary_filetab.
In jit.c, function finalize_symtab, we can save the symtab object
returned by allocate_symtab and use it, it makes things simpler.
Change-Id: I4e51d6d4b40759de8768b61292e5e13c8eae2e38
g++ 11.1.0 has a bug where it will emit a negative
DW_AT_data_member_location in some cases:
$ cat test.cpp
#include <memory>
int
main()
{
std::unique_ptr<int> ptr;
}
$ g++ -g test.cpp
$ llvm-dwarfdump -F a.out
...
0x00000964: DW_TAG_member
DW_AT_name [DW_FORM_strp] ("_M_head_impl")
DW_AT_decl_file [DW_FORM_data1] ("/usr/include/c++/11.1.0/tuple")
DW_AT_decl_line [DW_FORM_data1] (125)
DW_AT_decl_column [DW_FORM_data1] (0x27)
DW_AT_type [DW_FORM_ref4] (0x0000067a "default_delete<int>")
DW_AT_data_member_location [DW_FORM_sdata] (-1)
...
This leads to a GDB crash (when built with ASan, otherwise probably
garbage results), since it tries to read just before (to the left, in
ASan speak) of the value's buffer:
==888645==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020000c52af at pc 0x7f711b239f4b bp 0x7fff356bd470 sp 0x7fff356bcc18
READ of size 1 at 0x6020000c52af thread T0
#0 0x7f711b239f4a in __interceptor_memcpy /build/gcc/src/gcc/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:827
#1 0x555c4977efa1 in value_contents_copy_raw /home/simark/src/binutils-gdb/gdb/value.c:1347
#2 0x555c497909cd in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3126
#3 0x555c478f2eaa in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:333
#4 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#5 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#6 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#10 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#11 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#12 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#13 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
#14 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
#15 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
#16 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#17 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#18 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#19 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#20 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#21 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
#22 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
#23 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
#24 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#25 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#26 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#27 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
#28 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
#29 0x555c4760f04c in c_value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:587
#30 0x555c483ff954 in language_defn::value_print(value*, ui_file*, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:614
#31 0x555c49759f61 in value_print(value*, ui_file*, value_print_options const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1189
#32 0x555c48950f70 in print_formatted /home/simark/src/binutils-gdb/gdb/printcmd.c:337
#33 0x555c48958eda in print_value(value*, value_print_options const&) /home/simark/src/binutils-gdb/gdb/printcmd.c:1258
#34 0x555c48959891 in print_command_1 /home/simark/src/binutils-gdb/gdb/printcmd.c:1367
#35 0x555c4895a3df in print_command /home/simark/src/binutils-gdb/gdb/printcmd.c:1458
#36 0x555c4767f974 in do_simple_func /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:97
#37 0x555c47692e25 in cmd_func(cmd_list_element*, char const*, int) /home/simark/src/binutils-gdb/gdb/cli/cli-decode.c:2475
#38 0x555c4936107e in execute_command(char const*, int) /home/simark/src/binutils-gdb/gdb/top.c:670
#39 0x555c485f1bff in catch_command_errors /home/simark/src/binutils-gdb/gdb/main.c:523
#40 0x555c485f249c in execute_cmdargs /home/simark/src/binutils-gdb/gdb/main.c:618
#41 0x555c485f6677 in captured_main_1 /home/simark/src/binutils-gdb/gdb/main.c:1317
#42 0x555c485f6c83 in captured_main /home/simark/src/binutils-gdb/gdb/main.c:1338
#43 0x555c485f6d65 in gdb_main(captured_main_args*) /home/simark/src/binutils-gdb/gdb/main.c:1363
#44 0x555c46e41ba8 in main /home/simark/src/binutils-gdb/gdb/gdb.c:32
#45 0x7f71198bcb24 in __libc_start_main (/usr/lib/libc.so.6+0x27b24)
#46 0x555c46e4197d in _start (/home/simark/build/binutils-gdb-one-target/gdb/gdb+0x77f197d)
0x6020000c52af is located 1 bytes to the left of 8-byte region [0x6020000c52b0,0x6020000c52b8)
allocated by thread T0 here:
#0 0x7f711b2b7459 in __interceptor_calloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:154
#1 0x555c470acdc9 in xcalloc /home/simark/src/binutils-gdb/gdb/alloc.c:100
#2 0x555c49b775cd in xzalloc(unsigned long) /home/simark/src/binutils-gdb/gdbsupport/common-utils.cc:29
#3 0x555c4977bdeb in allocate_value_contents /home/simark/src/binutils-gdb/gdb/value.c:1029
#4 0x555c4977be25 in allocate_value(type*) /home/simark/src/binutils-gdb/gdb/value.c:1040
#5 0x555c4979030d in value_primitive_field(value*, long, int, type*) /home/simark/src/binutils-gdb/gdb/value.c:3092
#6 0x555c478f6280 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:501
#7 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#8 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#9 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#10 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#11 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#12 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#13 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#14 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#15 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
#16 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
#17 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
#18 0x555c478f63b2 in cp_print_value /home/simark/src/binutils-gdb/gdb/cp-valprint.c:513
#19 0x555c478f02ca in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:161
#20 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#21 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#22 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#23 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
#24 0x555c49759b17 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) /home/simark/src/binutils-gdb/gdb/valprint.c:1151
#25 0x555c478f2fcb in cp_print_value_fields(value*, ui_file*, int, value_print_options const*, type**, int) /home/simark/src/binutils-gdb/gdb/cp-valprint.c:335
#26 0x555c4760d45f in c_value_print_struct /home/simark/src/binutils-gdb/gdb/c-valprint.c:383
#27 0x555c4760df4c in c_value_print_inner(value*, ui_file*, int, value_print_options const*) /home/simark/src/binutils-gdb/gdb/c-valprint.c:438
#28 0x555c483ff9a7 in language_defn::value_print_inner(value*, ui_file*, int, value_print_options const*) const /home/simark/src/binutils-gdb/gdb/language.c:632
#29 0x555c49758b68 in do_val_print /home/simark/src/binutils-gdb/gdb/valprint.c:1048
Since there are some binaries with this in the wild, I think it would be
useful for GDB to work around this. I did the obvious simple thing, if
the DW_AT_data_member_location's value is -1, replace it with 0. I
added a producer check to only apply this fixup for GCC 11. The idea is
that if some other compiler ever uses a DW_AT_data_member_location value
of -1 by mistake, we don't know (before analyzing the bug at least) if
they did mean 0 or some other value. So I wouldn't want to apply the
fixup in that case.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063
Change-Id: Ieef3459b0b9bbce8bdad838ba83b4b64e7269d42
