The evaluate_for_locexpr_baton is the last derived class from the
dwarf_expr_context class. It's purpose is to support the passed in
buffer functionality.
Although, it is not really necessary to merge this class with it's
base class, doing that simplifies new expression evaluator design.
Considering that this functionality is going around the DWARF standard,
it is also reasonable to expect that with a new evaluator design and
extending the push object address functionality to accept any location
description, there will be no need to support passed in buffers.
Alternatively, it would also makes sense to abstract the interaction
between the evaluator and a given resource in the near future. The
passed in buffer would then be a specialization of that abstraction.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::read_mem): Merge with
evaluate_for_locexpr_baton implementation.
* dwarf2/loc.c (class evaluate_for_locexpr_baton): Remove
class.
(evaluate_for_locexpr_baton::read_mem): Move to
dwarf_expr_context.
(dwarf2_locexpr_baton_eval): Instantiate dwarf_expr_context
instead of evaluate_for_locexpr_baton class.
There are no virtual methods that require different specialization in
dwarf_expr_context class. This means that derived classes
dwarf_expr_executor and dwarf_evaluate_loc_desc are not needed any
more.
As a result of this, the evaluate_for_locexpr_baton class base class
is now the dwarf_expr_context class.
There might be a need for a better class hierarchy when we know more
about the direction of the future DWARF versions and gdb extensions,
but that is out of the scope of this patch series.
gdb/ChangeLog:
* dwarf2/frame.c (class dwarf_expr_executor): Remove class.
(execute_stack_op): Instantiate dwarf_expr_context instead of
dwarf_evaluate_loc_desc class.
* dwarf2/loc.c (class dwarf_evaluate_loc_desc): Remove class.
(dwarf2_evaluate_loc_desc_full): Instantiate dwarf_expr_context
instead of dwarf_evaluate_loc_desc class.
(struct evaluate_for_locexpr_baton): Derive from
dwarf_expr_context.
The get_reg_value method is a small function that is only called once,
so it can be inlined to simplify the dwarf_expr_context class.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::get_reg_value): Remove
method.
(dwarf_expr_context::execute_stack_op): Inline get_reg_value
method.
* dwarf2/expr.h (dwarf_expr_context::get_reg_value): Remove
method.
Following the idea of merging the evaluators, the
push_dwarf_reg_entry_value method can be moved from
dwarf_expr_executor and dwarf_evaluate_loc_desc classes
to their base class dwarf_expr_context.
gdb/ChangeLog:
* dwarf2/expr.c
(dwarf_expr_context::push_dwarf_reg_entry_value): Move from
dwarf_evaluate_loc_desc.
* dwarf2/frame.c
(dwarf_expr_executor::push_dwarf_reg_entry_value): Remove
method.
* dwarf2/loc.c (dwarf_expr_reg_to_entry_parameter): Expose
function.
(dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value): Move to
dwarf_expr_context.
* dwarf2/loc.h (dwarf_expr_reg_to_entry_parameter): Expose
function.
Following the idea of merging the evaluators, the read_mem method can
be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc classes
to their base class dwarf_expr_context.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::read_mem): Move from
dwarf_evaluate_loc_desc.
* dwarf2/frame.c (dwarf_expr_executor::read_mem): Remove
method.
* dwarf2/loc.c (dwarf_evaluate_loc_desc::read_mem): Move to
dwarf_expr_context.
Following the idea of merging the evaluators, the get_object_address
and can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
classes to their base class dwarf_expr_context.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::get_object_address): Move
from dwarf_evaluate_loc_desc.
(class dwarf_expr_context): Add object address member to
dwarf_expr_context.
* dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
method.
* dwarf2/frame.c (dwarf_expr_executor::get_object_address):
Remove method.
* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_object_address):
move to dwarf_expr_context.
(class dwarf_evaluate_loc_desc): Move object address member to
dwarf_expr_context.
Following the idea of merging the evaluators, the dwarf_call and
get_frame_pc method can be moved from dwarf_expr_executor and
dwarf_evaluate_loc_desc classes to their base class dwarf_expr_context.
Once this is done, the get_frame_pc can be replace with lambda
function.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::dwarf_call): Move from
dwarf_evaluate_loc_desc.
(dwarf_expr_context::get_frame_pc): Replace with lambda.
* dwarf2/expr.h (dwarf_expr_context::get_frame_pc): Remove
method.
* dwarf2/frame.c (dwarf_expr_executor::dwarf_call): Remove
method.
(dwarf_expr_executor::get_frame_pc): Remove method.
* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_pc): Remove
method.
(dwarf_evaluate_loc_desc::dwarf_call): Move to
dwarf_expr_context.
(per_cu_dwarf_call): Inline function.
This patch moves the compilation unit context information and support
from dwarf_expr_executor and dwarf_evaluate_loc_desc to
dwarf_expr_context evaluator. The idea is to report an error when a
given operation requires a compilation unit information to be resolved,
which is not available.
With this change, it also makes sense to always acquire ref_addr_size
information from the compilation unit context, considering that all
DWARF operations that refer to that information require a compilation
unit context to be present during their evaluation.
gdb/ChangeLog:
* dwarf2/expr.c (ensure_have_per_cu): New function.
(dwarf_expr_context::dwarf_expr_context): Add compilation unit
context information.
(dwarf_expr_context::get_base_type): Move from
dwarf_evaluate_loc_desc.
(dwarf_expr_context::get_addr_index): Remove method.
(dwarf_expr_context::dwarf_variable_value): Remove method.
(dwarf_expr_context::execute_stack_op): Call compilation unit
context info check. Inline get_addr_index and
dwarf_variable_value methods.
* dwarf2/expr.h (struct dwarf_expr_context): Add compilation
context info.
(dwarf_expr_context::get_addr_index): Remove method.
(dwarf_expr_context::dwarf_variable_value): Remove method.
(dwarf_expr_context::ref_addr_size): Remove member.
* dwarf2/frame.c (dwarf_expr_executor::get_addr_index): Remove
method.
(dwarf_expr_executor::dwarf_variable_value): Remove method.
* dwarf2/loc.c (sect_variable_value): Expose function.
(dwarf_evaluate_loc_desc::get_addr_index): Remove method.
(dwarf_evaluate_loc_desc::dwarf_variable_value): Remove method.
(class dwarf_evaluate_loc_desc): Move compilation unit context
information to dwarf_expr_context class.
* dwarf2/loc.h (sect_variable_value): Expose function.
Following the idea of merging the evaluators, the get_frame_cfa method
can be moved from dwarf_expr_executor and dwarf_evaluate_loc_desc
classes to their base class dwarf_expr_context. Once this is done,
it becomes apparent that the method is only called once and it can be
inlined.
It is also necessary to check if the frame context information was
provided before the DW_OP_call_frame_cfa operation is executed.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::get_frame_cfa): Remove
method.
(dwarf_expr_context::execute_stack_op): Call frame context info
check for DW_OP_call_frame_cfa. Remove use of get_frame_cfa.
* dwarf2/expr.h (dwarf_expr_context::get_frame_cfa): Remove
method.
* dwarf2/frame.c (dwarf_expr_context::get_frame_cfa): Remove
method.
* dwarf2/loc.c (dwarf_expr_context::get_frame_cfa): Remove
method.
Following 15 patches in this patch series is cleaning up the design of
the DWARF expression evaluator (dwarf_expr_context) to make future
extensions of that evaluator easier and cleaner to implement.
There are three subclasses of the dwarf_expr_context class
(dwarf_expr_executor, dwarf_evaluate_loc_desc and
evaluate_for_locexpr_baton). Here is a short description of each class:
- dwarf_expr_executor is evaluating a DWARF expression in a context
of a Call Frame Information. The overridden methods of this subclass
report an error if a specific DWARF operation, represented by that
method, is not allowed in a CFI context. The source code of this
subclass lacks the support for composite as well as implicit pointer
location description.
- dwarf_evaluate_loc_desc can evaluate any expression with no
restrictions. All of the methods that this subclass overrides are
actually doing what they are intended to do. This subclass contains
a full support for all location description types.
- evaluate_for_locexpr_baton subclass is a specialization of the
dwarf_evaluate_loc_desc subclass and it's function is to add
support for passed in buffers. This seems to be a way to go around
the fact that DWARF standard lacks a bit offset support for memory
location descriptions as well as using any location description for
the push object address functionality.
It all comes down to this question: what is a function of a DWARF
expression evaluator?
Is it to evaluate the expression in a given context or to check the
correctness of that expression in that context?
Currently, the only reason why there is a dwarf_expr_executor subclass
is to report an invalid DWARF expression in a context of a CFI, but is
that what the evaluator is supposed to do considering that the evaluator
is not tied to a given DWARF version?
There are more and more vendor and GNU extensions that are not part of
the DWARF standard, so is it that impossible to expect that some of the
extensions could actually lift the previously imposed restrictions of
the CFI context? Not to mention that every new DWARF version is lifting
some restrictions anyway.
The thing that makes more sense for an evaluator to do, is to take the
context of an evaluation and checks the requirements of every operation
evaluated against that context. With this approach, the evaluator would
report an error only if parts of the context, necessary for the
evaluation, are missing.
If this approach is taken, then the unification of the
dwarf_evaluate_loc_desc, dwarf_expr_executor and dwarf_expr_context
is the next logical step. This makes a design of the DWARF expression
evaluator cleaner and allows more flexibility when supporting future
vendor and GNU extensions.
Additional benefit here is that now all evaluators have access to all
location description types, which means that a vendor extended CFI
rules could support composite location description as well. This also
means that a new evaluator interface can be changed to return a single
struct value (that describes the result of the evaluation) instead of
a caller poking around the dwarf_expr_context internal data for answers
(like it is done currently).
This patch starts the merging process by moving the frame context
information and support from dwarf_expr_executor and
dwarf_evaluate_loc_desc to dwarf_expr_context evaluator. The idea
is to report an error when a given operation requires a frame
information to be resolved, if that information is not present.
gdb/ChangeLog:
* dwarf2/expr.c (ensure_have_frame): New function.
(read_addr_from_reg): Add from frame.c.
(dwarf_expr_context::dwarf_expr_context): Add frame info to
dwarf_expr_context.
(dwarf_expr_context::read_addr_from_reg): Remove.
(dwarf_expr_context::get_reg_value): Move from
dwarf_evaluate_loc_desc.
(dwarf_expr_context::get_frame_base): Move from
dwarf_evaluate_loc_desc.
(dwarf_expr_context::execute_stack_op): Call frame context info
check. Remove use of read_addr_from_reg method.
* dwarf2/expr.h (struct dwarf_expr_context): Add frame info
member, read_addr_from_reg, get_reg_value and get_frame_base
declaration.
(read_addr_from_reg): Move to expr.c.
* dwarf2/frame.c (read_addr_from_reg): Move to
dwarf_expr_context.
(dwarf_expr_executor::read_addr_from_reg): Remove.
(dwarf_expr_executor::get_frame_base): Remove.
(dwarf_expr_executor::get_reg_value): Remove.
(execute_stack_op): Use read_addr_from_reg function instead of
read_addr_from_reg method.
* dwarf2/loc.c (dwarf_evaluate_loc_desc::get_frame_base): Move
to dwarf_expr_context.
(dwarf_evaluate_loc_desc::get_reg_value): Move to
dwarf_expr_context.
(dwarf_evaluate_loc_desc::read_addr_from_reg): Remove.
(dwarf2_locexpr_baton_eval):Use read_addr_from_reg function
instead of read_addr_from_reg method.
Move the initial values for dwarf_expr_context class data members
to the class declaration in expr.h.
gdb/ChangeLog:
* dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context):
Remove initial data members values.
* dwarf2/expr.h (dwarf_expr_context): Add initial values
to the class data members.
This patch addresses a design problem with the symbol_needs_eval_context
class. It exposes the problem by introducing two new testsuite test
cases.
To explain the issue, I first need to explain the dwarf_expr_context
class that the symbol_needs_eval_context class derives from.
The intention behind the dwarf_expr_context class is to commonize the
DWARF expression evaluation mechanism for different evaluation
contexts. Currently in gdb, the evaluation context can contain some or
all of the following information: architecture, object file, frame and
compilation unit.
Depending on the information needed to evaluate a given expression,
there are currently three distinct DWARF expression evaluators:
- Frame: designed to evaluate an expression in the context of a call
frame information (dwarf_expr_executor class). This evaluator doesn't
need a compilation unit information.
- Location description: designed to evaluate an expression in the
context of a source level information (dwarf_evaluate_loc_desc
class). This evaluator expects all information needed for the
evaluation of the given expression to be present.
- Symbol needs: designed to answer a question about the parts of the
context information required to evaluate a DWARF expression behind a
given symbol (symbol_needs_eval_context class). This evaluator
doesn't need a frame information.
The functional difference between the symbol needs evaluator and the
others is that this evaluator is not meant to interact with the actual
target. Instead, it is supposed to check which parts of the context
information are needed for the given DWARF expression to be evaluated by
the location description evaluator.
The idea is to take advantage of the existing dwarf_expr_context
evaluation mechanism and to fake all required interactions with the
actual target, by returning back dummy values. The evaluation result is
returned as one of three possible values, based on operations found in a
given expression:
- SYMBOL_NEEDS_NONE,
- SYMBOL_NEEDS_REGISTERS and
- SYMBOL_NEEDS_FRAME.
The problem here is that faking results of target interactions can yield
an incorrect evaluation result.
For example, if we have a conditional DWARF expression, where the
condition depends on a value read from an actual target, and the true
branch of the condition requires a frame information to be evaluated,
while the false branch doesn't, fake target reads could conclude that a
frame information is not needed, where in fact it is. This wrong
information would then cause the expression to be actually evaluated (by
the location description evaluator) with a missing frame information.
This would then crash the debugger.
The gdb.dwarf2/symbol_needs_eval_fail.exp test introduces this
scenario, with the following DWARF expression:
DW_OP_addr $some_variable
DW_OP_deref
# conditional jump to DW_OP_bregx
DW_OP_bra 4
DW_OP_lit0
# jump to DW_OP_stack_value
DW_OP_skip 3
DW_OP_bregx $dwarf_regnum 0
DW_OP_stack_value
This expression describes a case where some variable dictates the
location of another variable. Depending on a value of some_variable, the
variable whose location is described by this expression is either read
from a register or it is defined as a constant value 0. In both cases,
the value will be returned as an implicit location description on the
DWARF stack.
Currently, when the symbol needs evaluator fakes a memory read from the
address behind the some_variable variable, the constant value 0 is used
as the value of the variable A, and the check returns the
SYMBOL_NEEDS_NONE result.
This is clearly a wrong result and it causes the debugger to crash.
The scenario might sound strange to some people, but it comes from a
SIMD/SIMT architecture where $some_variable is an execution mask. In
any case, it is a valid DWARF expression, and GDB shouldn't crash while
evaluating it. Also, a similar example could be made based on a
condition of the frame base value, where if that value is concluded to
be 0, the variable location could be defaulted to a TLS based memory
address.
The gdb.dwarf2/symbol_needs_eval_timeout.exp test introduces a second
scenario. This scenario is a bit more abstract due to the DWARF
assembler lacking the CFI support, but it exposes a different
manifestation of the same problem. Like in the previous scenario, the
DWARF expression used in the test is valid:
DW_OP_lit1
DW_OP_addr $some_variable
DW_OP_deref
# jump to DW_OP_fbreg
DW_OP_skip 4
DW_OP_drop
DW_OP_fbreg 0
DW_OP_dup
DW_OP_lit0
DW_OP_eq
# conditional jump to DW_OP_drop
DW_OP_bra -9
DW_OP_stack_value
Similarly to the previous scenario, the location of a variable A is an
implicit location description with a constant value that depends on a
value held by a global variable. The difference from the previous case
is that DWARF expression contains a loop instead of just one branch. The
end condition of that loop depends on the expectation that a frame base
value is never zero. Currently, the act of faking the target reads will
cause the symbol needs evaluator to get stuck in an infinite loop.
Somebody could argue that we could change the fake reads to return
something else, but that would only hide the real problem.
The general impression seems to be that the desired design is to have
one class that deals with parsing of the DWARF expression, while there
are virtual methods that deal with specifics of some operations.
Using an evaluator mechanism here doesn't seem to be correct, because
the act of evaluation relies on accessing the data from the actual
target with the possibility of skipping the evaluation of some parts of
the expression.
To better explain the proposed solution for the issue, I first need to
explain a couple more details behind the current design:
There are multiple places in gdb that handle DWARF expression parsing
for different purposes. Some are in charge of converting the expression
to some other internal representation (decode_location_expression,
disassemble_dwarf_expression and dwarf2_compile_expr_to_ax), some are
analysing the expression for specific information
(compute_stack_depth_worker) and some are in charge of evaluating the
expression in a given context (dwarf_expr_context::execute_stack_op
and decode_locdesc).
The problem is that all those functions have a similar (large) switch
statement that handles each DWARF expression operation. The result of
this is a code duplication and harder maintenance.
As a step into the right direction to solve this problem (at least for
the purpose of a DWARF expression evaluation) the expression parsing was
commonized inside of an evaluator base class (dwarf_expr_context). This
makes sense for all derived classes, except for the symbol needs
evaluator (symbol_needs_eval_context) class.
As described previously the problem with this evaluator is that if the
evaluator is not allowed to access the actual target, it is not really
evaluating.
Instead, the desired function of a symbol needs evaluator seems to fall
more into expression analysis category. This means that a more natural
fit for this evaluator is to be a symbol needs analysis, similar to the
existing compute_stack_depth_worker analysis.
Another problem is that using a heavyweight mechanism of an evaluator
to do an expression analysis seems to be an unneeded overhead. It also
requires a more complicated design of the parent class to support fake
target reads.
The reality is that the whole symbol_needs_eval_context class can be
replaced with a lightweight recursive analysis function, that will give
more correct result without compromising the design of the
dwarf_expr_context class. The analysis treats the expression byte
stream as a DWARF operation graph, where each graph node can be
visited only once and each operation can decide if the frame context
is needed for their evaluation.
The downside of this approach is adding of one more similar switch
statement, but at least this way the new symbol needs analysis will be
a lightweight mechnism and it will provide a correct result for any
given DWARF expression.
A more desired long term design would be to have one class that deals
with parsing of the DWARF expression, while there would be a virtual
methods that deal with specifics of some DWARF operations. Then that
class would be used as a base for all DWARF expression parsing mentioned
at the beginning.
This however, requires a far bigger changes that are out of the scope
of this patch series.
The new analysis requires the DWARF location description for the
argc argument of the main function to change in the assembly file
gdb.python/amd64-py-framefilter-invalidarg.S. Originally, expression
ended with a 0 value byte, which was never reached by the symbol needs
evaluator, because it was detecting a stack underflow when evaluating
the operation before. The new approach does not simulate a DWARF
stack anymore, so the 0 value byte needs to be removed because it
makes the DWARF expression invalid.
gdb/ChangeLog:
* dwarf2/loc.c (class symbol_needs_eval_context): Remove.
(dwarf2_get_symbol_read_needs): New function.
(dwarf2_loc_desc_get_symbol_read_needs): Remove.
(locexpr_get_symbol_read_needs): Use
dwarf2_get_symbol_read_needs.
gdb/testsuite/ChangeLog:
* gdb.python/amd64-py-framefilter-invalidarg.S : Update argc
DWARF location expression.
* lib/dwarf.exp (_location): Handle DW_OP_fbreg.
* gdb.dwarf2/symbol_needs_eval.c: New file.
* gdb.dwarf2/symbol_needs_eval_fail.exp: New file.
* gdb.dwarf2/symbol_needs_eval_timeout.exp: New file.
Since 4d7188abfd ("gdbsupport: add debug assertions in
gdb::optional::get"), some macro-related tests fail on Ubuntu 20.04 with
the system gcc 9.3.0 compiler when building with _GLIBCXX_DEBUG. For
example, gdb.base/info-macros.exp results in:
(gdb) break -qualified main
/home/smarchi/src/binutils-gdb/gdb/../gdbsupport/gdb_optional.h:206: internal-error: T& gdb::optional<T>::get() [with T = long unsigned int]: Assertion `this->has_value ()' failed.
The binary contains DWARF 4 debug info and includes a pre-standard
(pre-DWARF 5) .debug_macro section. The CU doesn't have a
DW_AT_str_offsets_base attribute (which doesn't exist in DWARF 4). The
field dwarf2_cu::str_offsets_base is therefore empty. At
dwarf2/read.c:24138, we unconditionally read the value in the optional,
which triggers the assertion shown above.
The same thing happens when building the test program with DWARF 5 with
the same gcc compiler, as that version of gcc doesn't use indirect
string forms, even with DWARF 5. So it still doesn't add a
DW_AT_str_offsets_base attribute on the CU.
Fix that by propagating down a gdb::optional<ULONGEST> for the str
offsets base instead of ULONGEST. That value is only used in
dwarf_decode_macro_bytes, when encountering an "strx" macro operation
(DW_MACRO_define_strx or DW_MACRO_undef_strx). Add a check there that
we indeed have a value in the optional before reading it. This is
unlikely to happen, but could happen in theory with an erroneous file
that uses DW_MACRO_define_strx but does not provide a
DW_AT_str_offsets_base (in practice, some things would probably have
failed before and stopped processing of debug info). I tested the
complaint by inverting the condition and using a clang-compiled binary,
which uses the strx operators. This is the result:
During symbol reading: use of DW_MACRO_define_strx with unknown string offsets base [in module /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/info-macros/info-macros]
The test now passes cleanly with the setup mentioned above, and the
testsuite looks on par with how it was before 4d7188abfd.
Change-Id: I7ebd2724beb7b9b4178872374c2a177aea696e77
I saw this complaint when my code had some bug, and spotted the typo.
Fix it, and while at it mention DW_MACRO as well (it would be confusing
to only see DW_MACINFO with a file that uses a DWARF 5 .debug_macro
section). I contemplated the idea of passing the knowledge of whether
we are dealing with a .debug_macro section or .debug_macinfo section, to
print only the right one. But in the end, I don't think that trouble is
necessary for a complaint nobody is going to see.
Change-Id: I276ce8da65c3eac5304f64a1e246358ed29cdbbc
[ I've confused things by forgetting to add -gdwarf-4 in $subject of
commit 0057a7ee0d "[gdb/testsuite] Add KFAILs for gdb.ada FAILs with
gcc-11". So I'm adding here -gdwarf-5 in $subject, even though -gdwarf-5 is
the default for gcc-11. I keep getting confused because of working with a
system gcc-11 compiler that was patched to switch the default back to
-gdwarf-4. ]
When running test-case gdb.ada/arrayptr.exp with gcc-11 (and default
-gdwarf-5), I run into:
...
(gdb) print pa_ptr.all^M
Unhandled dwarf expression opcode 0xff^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all
...
What happens is that pa_ptr:
...
<2><1523>: Abbrev Number: 3 (DW_TAG_variable)
<1524> DW_AT_name : pa_ptr
<1529> DW_AT_type : <0x14fa>
...
has type:
...
<2><14fa>: Abbrev Number: 2 (DW_TAG_typedef)
<14fb> DW_AT_name : foo__packed_array_ptr
<1500> DW_AT_type : <0x1504>
<2><1504>: Abbrev Number: 4 (DW_TAG_pointer_type)
<1505> DW_AT_byte_size : 8
<1505> DW_AT_type : <0x1509>
...
which is a pointer to a subrange:
...
<2><1509>: Abbrev Number: 12 (DW_TAG_subrange_type)
<150a> DW_AT_lower_bound : 0
<150b> DW_AT_upper_bound : 0x3fffffffffffffffff
<151b> DW_AT_name : foo__packed_array
<151f> DW_AT_type : <0x15cc>
<1523> DW_AT_artificial : 1
<1><15cc>: Abbrev Number: 5 (DW_TAG_base_type)
<15cd> DW_AT_byte_size : 16
<15ce> DW_AT_encoding : 7 (unsigned)
<15cf> DW_AT_name : long_long_long_unsigned
<15d3> DW_AT_artificial : 1
...
with upper bound of form DW_FORM_data16.
In gdb/dwarf/attribute.h we have:
...
/* Return non-zero if ATTR's value falls in the 'constant' class, or
zero otherwise. When this function returns true, you can apply
the constant_value method to it.
...
DW_FORM_data16 is not considered as constant_value cannot handle
that. */
bool form_is_constant () const;
...
so instead we have attribute::form_is_block (DW_FORM_data16) == true.
Then in attr_to_dynamic_prop for the upper bound, we get a PROC_LOCEXPR
instead of a PROP_CONST and end up trying to evaluate the constant
0x3fffffffffffffffff as if it were a locexpr, which causes the
"Unhandled dwarf expression opcode 0xff".
In contrast, with -gdwarf-4 we have:
...
<164c> DW_AT_upper_bound : 18 byte block: \
9e 10 ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 \
(DW_OP_implicit_value 16 byte block: \
ff ff ff ff ff ff ff ff 3f 0 0 0 0 0 0 0 )
...
Fix the dwarf error by translating the DW_FORM_data16 constant into a
PROC_LOCEXPR, effectively by prepending 0x9e 0x10, such that we have same
result as with -gdwarf-4:
...
(gdb) print pa_ptr.all^M
That operation is not available on integers of more than 8 bytes.^M
(gdb) KFAIL: gdb.ada/arrayptr.exp: scenario=all: print pa_ptr.all \
(PRMS: gdb/20991)
...
Tested on x86_64-linux, with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-5.
gdb/ChangeLog:
2021-07-25 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.
When run with the gdb-index or debug-names target boards, dup-psym.exp
fails. This came up for me because my new DWARF scanner reuses this
part of the existing index code, and so it registers as a regression.
This is PR symtab/25834.
Looking into this, I found that the DWARF index code here is fairly
different from the psymtab code. I don't think there's a deep reason
for this, and in fact, it seemed to me that the index code could
simply mimic what the psymtab code already does.
That is what this patch implements. The DW_AT_name and DW_AT_comp_dir
are now stored in the quick file names table. This may require
allocating a quick file names table even when DW_AT_stmt_list does not
exist. Then, the functions that work with this data are changed to
use find_source_or_rewrite, just as the psymbol code does. Finally,
line_header::file_full_name is removed, as it is no longer needed.
Currently, the index maintains a hash table of "quick file names".
The hash table uses a deletion function to free the "real name"
components when necessary. There's also a second such function to
implement the forget_cached_source_info method.
This bug fix patch will create a quick file name object even when
there is no DW_AT_stmt_list, meaning that the object won't be entered
in the hash table. So, this patch changes the memory management
approach so that the entries are cleared when the per-BFD object is
destroyed. (A dwarf2_per_cu_data destructor is not introduced,
because we have been avoiding adding a vtable to that class.)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
map_symbol_filenames can skip type units -- in fact I think it has to,
due to the assertion at the top of dw2_get_file_names. This may be a
regression due to the TU/CU unification patch, I did not check.
The DWARF index file name caching code only records when a line table
has been read and the reading failed. However, the code would be
simpler if it recorded any attempt, which is what this patch
implements.
file_and_directory carries a std::string in case the compilation
directory is computed, but a subsequent patch wants to preserve this
string without also having to maintain the storage for it. So, this
patch arranges for the compilation directory string to be stored in
the per-BFD string bcache instead.
This patch removes the redundant "comp_unit" parameter from
compute_include_file_name, and arranges to pass a file_and_directory
object from the readers down to this function. It also changes the
partial symtab reader to use find_file_and_directory, rather than
reimplement this functionality by hand.
In order to fix an index-related regression, I want to use
psymtab_include_file_name in the DWARF index file-handling code. This
patch renames this function and changes it to no longer require a
partial symtab to be passed in. A subsequent patch will further
refactor this code to remove the redundant parameter (which was always
there but is now more obvious).
While working on my series to replace the DWARF psymbol reader, I
noticed that the expand_symtabs_matching has an undocumented
invariant. I think that, if this invariant is not followed, then GDB
will crash. So, this patch documents this in the relevant spots and
introduces some asserts to make it clear.
Regression tested on x86-64 Fedora 32.
During prefix resolution, if the parent is a subprogram, there is no need
to go to the parent of the subprogram. The DIE will be local.
For a program like:
~~~
class F1
{
public:
int a;
int
vvv ()
{
class F2
{
int f;
};
F2 abcd;
return 1;
}
};
~~~
The class F2 should not be seen as a member of F1.
Before:
~~~
(gdb) ptype abcd
type = class F1::F2 {
private:
int f;
}
~~~
After:
~~~
(gdb) ptype abcd
type = class F2 {
private:
int f;
}
~~~
gdb/ChangeLog:
2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com>
* dwarf2/read.c (determine_prefix): Return an empty prefix if the
parent is a subprogram.
gdb/testsuite/ChangeLog:
2021-06-23 Felix Willgerodt <felix.willgerodt@intel.com>
* gdb.cp/nested-class-func-class.cc: New file.
* gdb.cp/nested-class-func-class.exp: New file.
Tom Tromey observed that when changing the language in
gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed.
This is due to this code in process_imported_unit_die:
...
/* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
into another compilation unit, at root level. Regard this as a hint,
and ignore it. */
if (die->parent && die->parent->parent == NULL
&& per_cu->unit_type == DW_UT_compile
&& per_cu->lang == language_cplus)
return;
...
which should have a partial symtabs counterpart.
Add the missing counterpart in process_psymtab_comp_unit.
Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config:
- using default gcc version 7.5.0
(with 5 unexpected FAILs)
- gcc 10.3.0 and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects
(with 1000 unexpected FAILs)
gdb/ChangeLog:
2021-07-06 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (scan_partial_symbols): Skip top-level imports of
c++ CU.
* testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ...
* testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here.
* testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test.
* testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test.
* testsuite/gdb.dwarf2/imported-unit.exp: Update.
This changes the .debug_names writer to find the TU indices in the
main loop over all CUs and TUs. (An earlier patch applied this same
treatment to the .gdb_index writer.)
write_gdbindex writes the CUs first, then walks the signatured type
hash table to write out the TUs. However, now that CUs and TUs are
unified in the DWARF reader, it's simpler to handle both of these in
the same loop.
My recent patch to unify CUs and TUs introduced an oddity in
write_gdbindex. Here, we pass 'i' to recursively_write_psymbols, but
we must instead pass 'counter', to handle the situation where a TU is
mixed in with the CUs.
I am not sure a test case for this is possible. I think it can only
happen when using DWARF 5, where a TU appears in .debug_info.
However, this situation is already not handled correctly by
.gdb_index. I filed a bug about this.
I noticed a couple of spots related to dwarf_decode_lines where the
'include_p' field was not being used idiomatically -- it is of type
bool now, so treat it as such.
gdb/ChangeLog
2021-07-03 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (lnp_state_machine::record_line): Use 'true'.
(dwarf_decode_lines): Remove '=='.
I wrote this while debugging a problem where the expected unwinder for a
frame wasn't used. It adds messages to show which unwinders are
considered for a frame, why they are not selected (if an exception is
thrown), and finally which unwinder is selected in the end.
To be able to show a meaningful, human-readable name for the unwinders,
add a "name" field to struct frame_unwind, and update all instances to
include a name.
Here's an example of the output:
[frame] frame_unwind_find_by_frame: this_frame=0
[frame] frame_unwind_try_unwinder: trying unwinder "dummy"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "inline"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "jit"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "python"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2"
[frame] frame_unwind_try_unwinder: yes
gdb/ChangeLog:
* frame-unwind.h (struct frame_unwind) <name>: New. Update
instances everywhere to include this field.
* frame-unwind.c (frame_unwind_try_unwinder,
frame_unwind_find_by_frame): Add debug messages.
Change-Id: I813f17777422425f0d08b22499817b23922e8ddb
Adds a new function to the quick_symbol_functions API to let us know
if there are any unexpanded symbols. This functionality is required
by a later commit. After this commit the functionality is unused, and
untested.
The new function objfile::has_unexpanded_symtabs is added to the
symfile-debug.c file which is a little strange, but this
is (currently) where many of the other objfile::* functions (that call
onto the quick_symbol_functions) are defined, so I'm reluctant to
break this pattern.
There should be no user visible changes after this commit.
gdb/ChangeLog:
* dwarf2/read.c (struct dwarf2_base_index_functions)
<has_unexpanded_symtabs>: Declare.
(dwarf2_base_index_functions::has_unexpanded_symtabs): Define new
function.
* objfiles.h (struct objfile) <has_unexpanded_symtabs>: Declare.
* psympriv.h (struct psymbol_functions) <has_unexpanded_symtabs>:
Declare.
* psymtab.c (psymbol_functions::has_unexpanded_symtabs): Define
new function.
* quick-symbol.h (struct quick_symbol_functions)
<has_unexpanded_symtabs>: Declare.
* symfile-debug.c (objfile::has_unexpanded_symtabs): Define new
function.
When GCC emits .debug_aranges, it adds padding to align the contents
to two times the address size. GCC has done this for many years --
but there is nothing in the DWARF standard that says this should be
done, and LLVM does not seem to add this padding.
It's simple to detect if the padding exists, though: if the contents
of one .debug_aranges CU (excluding the header) are not a multiple of
the alignment that GCC uses, then anything extra must be padding.
This patch changes gdb to correctly read both styles. It removes the
requirement that the padding bytes be zero, as this seemed
unnecessarily pedantic to me.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (create_addrmap_from_aranges): Change padding
logic.
gdb/testsuite/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* lib/gdb.exp (add_gdb_index, ensure_gdb_index): Add "style"
parameter.
* gdb.rust/dwindex.exp: New file.
* gdb.rust/dwindex.rs: New file.
dwarf2_cu has a 'language' value, but dwarf2_per_cu_data also holds a
value of this same type. There doesn't seem to be any reason to keep
two copies of this value. This patch removes the field from
dwarf2_cu, and arranges to set the value in the per-CU object instead.
Note that the value must still be set when expanding the full CU.
This is needed because the CUs will not be scanned when a DWARF index
is in use.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (process_psymtab_comp_unit): Don't set 'lang'.
(scan_partial_symbols, partial_die_parent_scope)
(add_partial_symbol, add_partial_subprogram)
(compute_delayed_physnames, rust_union_quirks)
(process_full_comp_unit, process_full_type_unit)
(process_imported_unit_die, process_die, dw2_linkage_name)
(dwarf2_compute_name, dwarf2_physname, read_import_statement)
(read_file_scope, queue_and_load_dwo_tu, read_func_scope)
(read_variable, dwarf2_get_subprogram_pc_bounds)
(dwarf2_attach_fields_to_type, dwarf2_add_member_fn)
(dwarf2_attach_fn_fields_to_type)
(quirk_ada_thick_pointer_struct, read_structure_type)
(handle_struct_member_die, process_structure_scope)
(read_array_type, read_array_order, prototyped_function_p)
(read_subroutine_type, dwarf2_init_complex_target_type)
(read_base_type, read_subrange_type, read_unspecified_type)
(load_partial_dies, partial_die_info::fixup, set_cu_language)
(new_symbol, need_gnat_info, determine_prefix, typename_concat)
(dwarf2_canonicalize_name, follow_die_offset)
(prepare_one_comp_unit): Update.
* dwarf2/cu.c (dwarf2_cu::start_symtab): Update.
The DWARF reader currently sets the CU's language in two different
spots. It is primarily done in prepare_one_comp_unit, but
read_file_scope also checks the producer and may change the language
based on the result.
This patch consolidates all language-setting into
prepare_one_comp_unit. set_cu_language is renamed and changed not to
set language_defn; instead that is done in prepare_one_comp_unit after
the correct language enum value is chosen.
This fixes a minor latent bug, which is that read_file_scope could set
the language enum value to language_opencl, but then neglected to
reset language_defn in this case.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (read_file_scope): Don't call set_cu_language.
(dwarf_lang_to_enum_language): Rename from set_cu_language. Don't
set language_defn. Handle DW_LANG_OpenCL.
(prepare_one_comp_unit): Check producer and set language_defn.
While working on the DWARF psymtab replacement, I needed
addrmap_foreach to accept a gdb::function_view. This seemed like a
worthwhile change on its own, so I've written it separately for
submission.
Regression tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-06-25 Tom Tromey <tom@tromey.com>
* dwarf2/index-write.c (struct addrmap_index_data): Add
initializers.
<operator()>: Declare.
(addrmap_index_data::operator()): Rename from
add_address_entry_worker. Remove 'datap' parameter.
(write_address_map): Update.
* psymtab.c (struct dump_psymtab_addrmap_data): Remove
(dump_psymtab_addrmap_1): Remove 'data' parameter, add other
parameters.
(dump_psymtab_addrmap): Update.
* addrmap.c (struct addrmap_funcs) <foreach>: Remove 'data'
parameter.
(addrmap_foreach, addrmap_fixed_foreach): Likewise.
(struct mutable_foreach_data): Remove.
(addrmap_mutable_foreach_worker): Update.
(addrmap_mutable_foreach): Remove 'data' parameter.
* addrmap.h (addrmap_foreach_fn): Use gdb::function_view.
(addrmap_foreach): Remove 'data' parameter.
Without that it is impossible to debug on riscv64.
gdb/
PR symtab/27999
* dwarf2/loc.c (decode_debug_loclists_addresses): Support
DW_LLE_start_end.
gdb/testsuite/
PR symtab/27999
* lib/dwarf.exp (start_end): New proc inside loclists.
* gdb.dwarf2/loclists-start-end.exp: New file.
* gdb.dwarf2/loclists-start-end.c: New file.
This is another attempt at fixing the problem described in commit 4cf88725da
"[gdb/symtab] Fix infinite recursion in dwarf2_cu::get_builder()", which was
reverted in commit 3db19b2d72.
First off, some context.
A DWARF CU can be viewed as a symbol table: toplevel children of a CU DIE
represent symbol table entries for that CU. Furthermore, there is a
hierarchy: a symbol table entry such as a function itself has a symbol table
containing parameters and local variables.
The dwarf reader maintains a notion of current symbol table (that is: the
symbol table a new symbol needs to be entered into) in dwarf2_cu member
list_in_scope.
A problem then presents itself when reading inter-CU references:
- a new symbol read from a CU B needs to be entered into the symbol table of
another CU A.
- the notion of current symbol table is tracked on a per-CU basis.
This is addressed in inherit_abstract_dies by temporarily overwriting the
list_in_scope for CU B with the one for CU A.
The current symbol table is one aspect of the current dwarf reader context
that is tracked, but there are more, f.i. ones that are tracked via the
dwarf2_cu member m_builder, f.i. m_builder->m_local_using_directives.
A similar problem exists in relation to inter-CU references, but a different
solution was chosen:
- to keep track of an ancestor field in dwarf2_cu, which is updated
when traversing inter-CU references, and
- to use the ancestor field in dwarf2_cu::get_builder to return the m_builder
in scope.
There is no actual concept of a CU having an ancestor, it just marks the most
recent CU from which a CU was inter-CU-referenced. Consequently, when
following inter-CU references from a CU A to another CU B and back to CU A,
the ancestors form a cycle, which causes dwarf2_cu::get_builder to hang or
segfault, as reported in PR26327.
ISTM that the ancestor implementation is confusing and fragile, and should
go. Furthermore, it seems that keeping track of the m_builder in scope can be
handled simply with a per-objfile variable.
Fix the hang / segfault by:
- keeping track of the m_builder in scope using a new variable
per_obj->sym_cu, and
- using it in dwarf2_cu::get_builder.
Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config:
- using default gcc version 7.5.0
(with 5 unexpected FAILs)
- gcc 10.3.0 and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects
(with 1000 unexpected FAILs)
gdb/ChangeLog:
2021-06-16 Tom de Vries <tdevries@suse.de>
PR symtab/26327
* dwarf2/cu.h (dwarf2_cu::ancestor): Remove.
(dwarf2_cu::get_builder): Declare and move ...
* dwarf2/cu.c (dwarf2_cu::get_builder): ... here. Use sym_cu instead
of ancestor. Assert return value is non-null.
* dwarf2/read.c (read_file_scope): Set per_objfile->sym_cu.
(follow_die_offset, follow_die_sig_1): Remove setting of ancestor.
(dwarf2_per_objfile): Add sym_cu field.
This is unused (and was event when it was introduced). Remove it.
gdb/ChangeLog:
* dwarf2/loc.h (struct call_site_stuff): Remove.
Change-Id: Iaa82cb7cfd9768998553b4c9211aca7529eb402f
Building GDB with current git (future 13) Clang runs into these two
issues:
#1:
src/gdb/symtab.h:1139:3: error: definition of implicit copy assignment operator for 'symbol' is deprecated because it has a user-declared copy constructor [-Werror,-Wdeprecated-copy]
symbol (const symbol &) = default;
^
#2:
src/gdb/dwarf2/read.c:834:23: error: definition of implicit copy constructor for 'partial_die_info' is deprecated because it has a user-declared copy assignment operator [-Werror,-Wdeprecated-copy]
partial_die_info& operator=(const partial_die_info& rhs) = delete;
^
Fix them by adding the explicit defaulted versions of copy ctor and
copy-assign op appropriately.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* dwarf2/read.c (struct partial_die_info): Add defaulted copy
ctor.
* symtab.h (struct symbol): Add defaulted copy assignment
operator.
With -fgnat-encodings=minimal, an internal version (these patches will
be upstreamed in the near future) of the Ada compiler can emit DWARF
for an array where the bound comes from a variable, like:
<1><12a7>: Abbrev Number: 7 (DW_TAG_array_type)
<12a8> DW_AT_name : (indirect string, offset: 0x1ae9): pck__my_array
[...]
<2><12b4>: Abbrev Number: 8 (DW_TAG_subrange_type)
<12b5> DW_AT_type : <0x1294>
<12b9> DW_AT_upper_bound : <0x1277>
With the upper bound DIE being:
<1><1277>: Abbrev Number: 2 (DW_TAG_variable)
<1278> DW_AT_name : (indirect string, offset: 0x1a4d): pck__my_length___U
<127c> DW_AT_type : <0x128f>
<1280> DW_AT_external : 1
<1280> DW_AT_artificial : 1
<1280> DW_AT_declaration : 1
Note that the variable is just a declaration -- in this situation, the
variable comes from another compilation unit, and must be found when
trying to compute the array bound.
This patch adds a new PROP_VARIABLE_NAME kind, to enable this search.
This same scenario can occur with DW_OP_GNU_variable_value, so this
patch adds support for that as well.
gdb/ChangeLog
2021-06-04 Tom Tromey <tromey@adacore.com>
* dwarf2/read.h (dwarf2_fetch_die_type_sect_off): Add 'var_name'
parameter.
* dwarf2/loc.c (dwarf2_evaluate_property) <case
PROP_VARIABLE_NAME>: New case.
(compute_var_value): New function.
(sect_variable_value): Use compute_var_value.
* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_TAG_variable.
(var_decl_name): New function.
(dwarf2_fetch_die_type_sect_off): Add 'var_name' parameter.
* gdbtypes.h (enum dynamic_prop_kind) <PROP_VARIABLE_NAME>: New
constant.
(union dynamic_prop_data) <variable_name>: New member.
(struct dynamic_prop) <variable_name, set_variable_name>: New
methods.
gdb/testsuite/ChangeLog
2021-06-04 Tom Tromey <tromey@adacore.com>
* gdb.ada/array_of_symbolic_length.exp: New file.
* gdb.ada/array_of_symbolic_length/foo.adb: New file.
* gdb.ada/array_of_symbolic_length/gl.adb: New file.
* gdb.ada/array_of_symbolic_length/gl.ads: New file.
* gdb.ada/array_of_symbolic_length/pck.adb: New file.
* gdb.ada/array_of_symbolic_length/pck.ads: New file.
All signatured_type constucted (even those used only for lookups in hash
maps) need a signature. Enforce that by passing the signature all the
way to the signatured_type constructor.
gdb/ChangeLog:
* dwarf2/read.h (struct structured_type) <signatured_type>: New.
Update all callers.
(struct dwarf2_per_bfd) <allocate_signatured_type>: Add
signature parameter, update all callers.
* dwar2/read.c (dwarf2_per_bfd::allocate_signatured_type): Add
signature parameter.
Change-Id: I99bc1f88f54127666aa133ddbbabb7f7668fa14a
Add an alias for std::unique_ptr<signatured_type> and use it where
possible.
gdb/ChangeLog:
* dwarf2/read.h (signatured_type_up): New, use where possible.
Change-Id: I5a41e8345551434c8beeb9f269b03bdcf27989be
Move them up before dwarf2_per_bfd, this will allow adding and using
signatured_type_up in the next patch.
gdb/ChangeLog:
* dwarf2/read.h (signatured_type, dwarf2_per_cu_data): Move up.
Change-Id: I85acad4476c8236930b6f9e53ddb8bbbad009e5e
All callers of allocate_signatured_type set the is_debug_types flag on
the result -- in fact, they are required to, because this is the sign
that downcasting the object to signatured_type is safe. This patch
moves this assignment into the allocation function.
2021-05-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_per_bfd::allocate_signatured_type): Set
is_debug_types.
(create_signatured_type_table_from_index)
(create_signatured_type_table_from_debug_names, add_type_unit)
(read_comp_units_from_section): Update.
Now that CUs and TUs are stored together in all_comp_units, the
m_num_psymtabs member is no longer needed -- it is always identical to
the length of the vector. This patch removes it.
2021-05-30 Tom Tromey <tom@tromey.com>
* dwarf2/read.h (struct dwarf2_per_bfd) <num_psymtabs,
m_num_psymtabs>: Remove.
(resize_symtabs): Update.
* dwarf2/read.c (dwarf2_per_bfd::allocate_per_cu)
(dwarf2_per_bfd::allocate_signatured_type): Update.
I spotted some indentation issues where we had some spaces followed by
tabs at beginning of line, that I wanted to fix. So while at it, I did
a quick grep to find and fix all I could find.
gdb/ChangeLog:
* Fix tab after space indentation issues throughout.
Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd
When running test-case gdb.dwarf2/dw2-dummy-cu.exp without -readnow, we run
into:
...
(gdb) file outputs/gdb.dwarf2/dw2-dummy-cu/dw2-dummy-cu^M
Reading symbols from outputs/gdb.dwarf2/dw2-dummy-cu/dw2-dummy-cu...^M
ERROR: Couldn't load dw2-dummy-cu into GDB (eof).
...
The problem is that we're running into a segfault:
...
Thread 1 "gdb" received signal SIGSEGV, Segmentation fault.
process_psymtab_comp_unit (this_cu=0x2141090, per_objfile=0x1aa4140,
want_partial_unit=false, pretend_language=language_minimal)
at /home/vries/gdb_versions/devel/src/gdb/dwarf2/read.c:7023
7023 switch (reader.comp_unit_die->tag)
...
due to reader.comp_unit_die == nullptr:
...
(gdb) p reader.comp_unit_die
$1 = (die_info *) 0x0
...
Indeed, there's no CU DIE in the test-case:
...
$ readelf -wi outputs/gdb.dwarf2/dw2-dummy-cu/dw2-dummy-cu
Contents of the .debug_info section:
Compilation Unit @ offset 0x0:
Length: 0x7 (32-bit)
Version: 2
Abbrev Offset: 0x0
Pointer Size: 4
$
...
Fix this by handling reader.comp_unit_die == nullptr in
process_psymtab_comp_unit.
Update the test-case to trigger this PR, as per PR27920 - "[gdb/testsuite]
hardcoding -readnow skips testing of partial symbols".
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-27 Tom de Vries <tdevries@suse.de>
PR symtab/27919
* dwarf2/read.c (process_psymtab_comp_unit):
gdb/testsuite/ChangeLog:
2021-05-27 Tom de Vries <tdevries@suse.de>
PR symtab/27919
PR testsuite/27920
* gdb.dwarf2/dw2-dummy-cu.exp: Use maint expand-symtabs instead of
-readnow.
When loading the debug info package
libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug from openSUSE Leap 15.2, we
run into a dwarf error:
...
$ gdb -q -batch libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug
Dwarf Error: Cannot not find DIE at 0x18a936e7 \
[from module libLLVM.so.10-10.0.1-lp152.30.4.x86_64.debug]
...
The DIE @ 0x18a936e7 does in fact exist, and is part of a CU @ 0x18a23e52.
No error message is printed when using -readnow.
What happens is the following:
- a dwarf2_per_cu_data P is created for the CU.
- a dwarf2_cu A is created for the same CU.
- another dwarf2_cu B is created for the same CU.
- the dwarf2_cu B is set in per_objfile->m_dwarf2_cus, such that
per_objfile->get_cu (P) returns B.
- P->load_all_dies is set to 1.
- all dies are read into the A->partial_dies htab
- dwarf2_cu A is destroyed.
- we try to find the partial_die for the DIE @ 0x18a936e7 in B->partial_dies.
We can't find it, but do not try to load all dies, because P->load_all_dies
is already set to 1.
- an error message is generated.
The question is why we're creating dwarf2_cu A and B for the same CU.
The dwarf2_cu A is created here:
...
(gdb) bt
#0 dwarf2_cu::dwarf2_cu (this=0x79a9660, per_cu=0x23c0b30,
per_objfile=0x1ad01b0) at dwarf2/cu.c:38
#1 0x0000000000675799 in cutu_reader::cutu_reader (this=0x7fffffffd040,
this_cu=0x23c0b30, per_objfile=0x1ad01b0, abbrev_table=0x0,
existing_cu=0x0, skip_partial=false) at dwarf2/read.c:6487
#2 0x0000000000676eb3 in process_psymtab_comp_unit (this_cu=0x23c0b30,
per_objfile=0x1ad01b0, want_partial_unit=false,
pretend_language=language_minimal) at dwarf2/read.c:7028
...
And the dwarf2_cu B is created here:
...
(gdb) bt
#0 dwarf2_cu::dwarf2_cu (this=0x885e8c0, per_cu=0x23c0b30,
per_objfile=0x1ad01b0) at dwarf2/cu.c:38
#1 0x0000000000675799 in cutu_reader::cutu_reader (this=0x7fffffffcc50,
this_cu=0x23c0b30, per_objfile=0x1ad01b0, abbrev_table=0x0,
existing_cu=0x0, skip_partial=false) at dwarf2/read.c:6487
#2 0x0000000000678118 in load_partial_comp_unit (this_cu=0x23c0b30,
per_objfile=0x1ad01b0, existing_cu=0x0) at dwarf2/read.c:7436
#3 0x000000000069721d in find_partial_die (sect_off=(unknown: 0x18a55054),
offset_in_dwz=0, cu=0x0) at dwarf2/read.c:19391
#4 0x000000000069755b in partial_die_info::fixup (this=0x9096900,
cu=0xa6a85f0) at dwarf2/read.c:19512
#5 0x0000000000697586 in partial_die_info::fixup (this=0x8629bb0,
cu=0xa6a85f0) at dwarf2/read.c:19516
#6 0x00000000006787b1 in scan_partial_symbols (first_die=0x8629b40,
lowpc=0x7fffffffcf58, highpc=0x7fffffffcf50, set_addrmap=0, cu=0x79a9660)
at dwarf2/read.c:7563
#7 0x0000000000678878 in scan_partial_symbols (first_die=0x796ebf0,
lowpc=0x7fffffffcf58, highpc=0x7fffffffcf50, set_addrmap=0, cu=0x79a9660)
at dwarf2/read.c:7580
#8 0x0000000000676b82 in process_psymtab_comp_unit_reader
(reader=0x7fffffffd040, info_ptr=0x7fffc1b3f29b, comp_unit_die=0x6ea90f0,
pretend_language=language_minimal) at dwarf2/read.c:6954
#9 0x0000000000676ffd in process_psymtab_comp_unit (this_cu=0x23c0b30,
per_objfile=0x1ad01b0, want_partial_unit=false,
pretend_language=language_minimal) at dwarf2/read.c:7057
...
So in frame #9, a cutu_reader is created with dwarf2_cu A. Then a fixup takes
us to the following CU @ 0x18aa33d6, in frame #5. And a similar fixup in
frame #4 takes us back to CU @ 0x18a23e52. At that point, there's no
information available that we're already trying to read that CU, and we end up
creating another cutu_reader with dwarf2_cu B.
It seems that there are two related problems:
- creating two dwarf2_cu's is not optimal
- the unoptimal case is not handled correctly
This patch addresses the last problem, by moving the load_all_dies flag from
dwarf2_per_cu_data to dwarf2_cu, such that it is paired with the partial_dies
field, which ensures that the two can be kept in sync.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-05-27 Tom de Vries <tdevries@suse.de>
PR symtab/27898
* dwarf2/cu.c (dwarf2_cu::dwarf2_cu): Add load_all_dies init.
* dwarf2/cu.h (dwarf2_cu): Add load_all_dies field.
* dwarf2/read.c (load_partial_dies, find_partial_die): Update.
* dwarf2/read.h (dwarf2_per_cu_data::dwarf2_per_cu_data): Remove
load_all_dies init.
(dwarf2_per_cu_data): Remove load_all_dies field.
This was wrong: dwarf_die_debug is used as an integer, for example where
it is passed to dump_die. It is documented in the command's help, which
I missed the first time.
This reverts commit 749369c430.
Change-Id: I1d09c3da57f8885f4f9fe9f4eae0cf86006e617a
