This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
Consider test-case gdb.base/vla-optimized-out.exp, compiled using clang-10.
GDB fails to get the size of the vla a:
...
(gdb) p sizeof (a)^M
Cannot access memory at address 0x6^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
The relevant DWARF looks like this: the variable a:
...
<2><12b>: Abbrev Number: 5 (DW_TAG_variable)
<12c> DW_AT_name : a
<132> DW_AT_type : <0x189>
...
has type:
...
<1><189>: Abbrev Number: 10 (DW_TAG_array_type)
<18a> DW_AT_type : <0x198>
<2><18e>: Abbrev Number: 11 (DW_TAG_subrange_type)
<18f> DW_AT_type : <0x19f>
<193> DW_AT_count : <0x117>
...
with the count attribute equated to the value of this artificial variable:
...
<2><117>: Abbrev Number: 4 (DW_TAG_variable)
<118> DW_AT_location : 10 byte block: 75 1 10 ff ff ff ff f 1a 9f \
(DW_OP_breg5 (rdi): 1;
DW_OP_constu: 4294967295;
DW_OP_and;
DW_OP_stack_value)
<123> DW_AT_name : __vla_expr0
<127> DW_AT_type : <0x182>
<12b> DW_AT_artificial : 1
...
The location description of the variable is terminated with DW_OP_stack_value,
which according to the DWARF spec means that "the DWARF expression represents
the actual value of the object, rather than its location".
However, in attr_to_dynamic_prop, we set is_reference to true:
...
baton->locexpr.is_reference = true;
...
and use it in dwarf2_evaluate_property to dereference the value of the DWARF
expression, which causes the access to memory at address 0x6.
Fix this by ignoring the baton->locexpr.is_reference == true setting if
the expression evaluation has ctx.location == DWARF_VALUE_STACK, such that we
get:
...
(gdb) p sizeof (a)^M
$2 = 6^M
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
Tested on x86_64-linux, with gcc.
Tested the following test-cases (the ones mentioned in PR26905) on
x86_64-linux with clang-10:
- gdb.base/vla-optimized-out.exp
- gdb.base/vla-ptr.exp
- gdb.mi/mi-vla-c99
gdb/ChangeLog:
2020-11-30 Tom de Vries <tdevries@suse.de>
PR symtab/26905
* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add and handle
is_reference parameter.
(dwarf2_evaluate_property): Update dwarf2_locexpr_baton_eval call.
gdb/testsuite/ChangeLog:
2020-11-30 Tom de Vries <tdevries@suse.de>
PR symtab/26905
* gdb.dwarf2/count.exp: Remove kfails.
This variable is really a boolean, so use the bool type.
gdb/ChangeLog:
* dwarf2/loc.c (dwarf2_loc_desc_get_symbol_read_needs): Use
bool.
Change-Id: I814a47d1200f3b88722c54c822fd49607a6b77be
Replace the function pointer + `void *` parameters of
dwarf2_fetch_die_loc_sect_off and dwarf2_fetch_die_loc_cu_off with a
function_view parameter. Change call sites to use a lambda function.
This improves type-safety, so reduces the chances of errors.
gdb/ChangeLog:
* read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Replace function pointer +
`void *` parameter with function_view.
* read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Likewise.
* loc.c (get_frame_pc_for_per_cu_dwarf_call): Remove.
(per_cu_dwarf_call): Adjust.
(get_frame_address_in_block_wrapper): Remove.
(indirect_synthetic_pointer): Adjust.
(get_ax_pc): Remove.
(dwarf2_compile_expr_to_ax): Adjust.
Change-Id: Ic9b6ced0c4128f2b75ca62e0ed638b0962a22859
Add setters, to ensure that the kind and value of the property are
always kept in sync (a caller can't forget one or the other). Add
getters, such that we can assert that when a caller accesses a data bit
of the property, the property is indeed of the corresponding kind.
Note that because of the way `struct dynamic_prop` is allocated
currently, we can't make the `m_kind` and `m_data` fields private. That
would make the type non-default-constructible, and we would have to call
the constructor when allocating them. However, I still prefixed them
with `m_` to indicate that they should not be accessed from outside the
class (and also to be able to use the name `kind` for the method).
gdb/ChangeLog:
* gdbtypes.h (struct dynamic_prop) <kind, set_undefined,
const_val, set_const_val, baton, set_locexpr, set_loclist,
set_addr_offset, variant_parts, set_variant_parts,
original_type, set_original_type>: New methods.
<kind>: Rename to...
<m_kind>: ... this. Update all users to use the new methods
instead.
<data>: Rename to...
<m_data>: ... this. Update all users to use the new methods
instead.
Change-Id: Ib72a8eb440dfeb1a5421d0933334230d7f2478f9
Add some empty lines at places I forgot in the previous patch.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loclists_addresses): Add empty
lines.
Change-Id: I8a9f3766ede1ce750e0703023285dca873bce0da
I always found that some switch statements in this file were a bit too
packed. I think having empty lines between each case helps with
reading. I'm pushing this as obvious, I hope it won't be too
controversial.
gdb/ChangeLog:
* dwarf2/loc.c (decode_debug_loc_dwo_addresses): Add empty
lines.
(dwarf2_find_location_expression): Likewise.
(call_site_parameter_matches): Likewise.
(dwarf2_compile_expr_to_ax): Likewise.
(disassemble_dwarf_expression): Likewise.
(loclist_describe_location): Likewise.
Change-Id: I381366a0468ff1793faa612c46ef48a9d4773192
Add a comment to clarify why we temporarily override some of the
context's fields, and especially the per_objfile field. A longer
explanation can be found in this previous commit
44486dcf19 ("gdb: use caller objfile in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value")
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Add comment.
Change-Id: I60c6e1062799f729b30a9db78bcb6448783324b4
In commit
89b07335fe ("Add dwarf2_per_objfile to dwarf_expr_context and dwarf2_frame_cache")
I replaced the offset property of dwarf_expr_context by a per_objfile
property (since we can get the text offset from the objfile). The
previous code in dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value
(dwarf_evaluate_loc_desc derives from dwarf_expr_context) did
temporarily override the offset property while evaluating a DWARF
sub-expression. I speculated that this sub-expression always came from
the same objfile as the outer expression, so I didn't see the need to
temporarily override the per_objfile property in the new code. A later
commit:
9f47c70716 ("Remove dwarf2_per_cu_data::objfile ()")
added the following assertion to verify this:
gdb_assert (this->per_objfile == caller_per_objfile);
It turns out that this is not true. Call sites can refer to function in
another objfile, and therefore the caller's objfile can be different
from the callee's objfile. This can happen when the call site DIE in the
DWARF represents a function call done through a function pointer. The
DIE can't describe statically which function is being called, since it's
variable and not known at compile time. Instead, it provides an
expression that evaluates to the address of the function being called.
In this case, the called function can very well be in a separate
objfile.
Fix this by overriding the per_objfile property while evaluating the
sub-expression.
This was exposed by the gdb.base/catch-load.exp test failing on openSUSE
Tumbleweed with the glibc debug info installed. It was also reported to
fail on Fedora.
When I investigated the problem, the particular call site on which we
did hit the assert was coming from this DIE, in
/usr/lib/debug/lib64/libc-2.31.so-2.31-5.1.x86_64.debug on openSUSE
Tumbleweed:
0x0091aa10: DW_TAG_GNU_call_site
DW_AT_low_pc [DW_FORM_addr] (0x00000000001398e0)
DW_AT_GNU_call_site_target [DW_FORM_exprloc] (DW_OP_fbreg -272, DW_OP_deref)
DW_AT_sibling [DW_FORM_ref4] (0x0091aa2b)
And for you curious out there, this call site is found in this function:
0x0091a91d: DW_TAG_subprogram
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_name [DW_FORM_strp] ("_dl_catch_exception")
DW_AT_decl_file [DW_FORM_data1] ("/usr/src/debug/glibc-2.31-5.1.x86_64/elf/dl-error-skeleton.c")
...
Which is a function that indeed uses a function pointer.
gdb/ChangeLog:
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<push_dwarf_reg_entry_value>: Remove assert. Override
per_objfile with caller_per_objfile.
Change-Id: Ib227d767ce525c10607ab6621a373aaae982c67a
Since dwarf2_per_cu_data objects are going to become
objfile-independent, the backlink from dwarf2_per_cu_data to one
particular objfile must be removed. Instead, users of
dwarf2_per_cu_data that need an objfile must know from somewhere else in
the context of which objfile they are using this CU.
This also helps remove a dwarf2_per_cu_data::dwarf2_per_objfile
reference (from where the objfile was obtained).
Note that the dwarf2_per_cu_data::objfile method has a special case to
make sure to return the main objfile, if the objfile associated to the
dwarf2_per_cu_data is a separate debug objfile. I don't really know if
this is necessary: I ignored that, and didn't see any regression when
testing with the various Dejagnu boards with separate debug info, so I
presume it wasn't needed. If it turns out this was needed, then we can
have a helper method on the objfile type for that.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <objfile>: Remove.
* dwarf2/read.c (dwarf2_compute_name): Pass per_objfile down.
(read_call_site_scope): Assign per_objfile.
(dwarf2_per_cu_data::objfile): Remove.
* gdbtypes.h (struct call_site) <per_objfile>: New member.
* dwarf2/loc.h (dwarf2_evaluate_loc_desc): Add
dwarf2_per_objfile parameter.
* dwarf2/loc.c (dwarf2_evaluate_loc_desc_full): Add
dwarf2_per_objfile parameter.
(dwarf_expr_reg_to_entry_parameter): Add output
dwarf2_per_objfile parameter.
(locexpr_get_frame_base): Update.
(class dwarf_evaluate_loc_desc) <get_tls_address>: Update.
<push_dwarf_reg_entry_value>: Update.
<call_site_to_target_addr>: Update.
(dwarf_entry_parameter_to_value): Add dwarf2_per_objfile
parameter.
(value_of_dwarf_reg_entry): Update.
(rw_pieced_value): Update.
(indirect_synthetic_pointer): Update.
(dwarf2_evaluate_property): Update.
(dwarf2_loc_desc_get_symbol_read_needs): Add dwarf2_per_objfile
parameter.
(locexpr_read_variable): Update.
(locexpr_get_symbol_read_needs): Update.
(loclist_read_variable): Update.
Change-Id: Idb40d1a94995af305054d463967bb6ce11a08f25
This method simply returns the text offset of the objfile associated to
the dwarf2_per_cu_data object. Since dwarf2_per_cu_data objects are
going to become objfile-independent, we can't keep this method. This
patch removes it.
Existing callers need to figure out the in the context of which objfile
this is being used, and call text_offset on it. Typically, this comes
from a symbol baton, where we store the corresponding
dwarf2_per_objfile.
gdb/ChangeLog:
* dwarf2/read.h (struct dwarf2_per_cu_data) <text_offset>:
Remove.
* dwarf2/read.c (dwarf2_per_cu_data::text_offset): Remove.
* dwarf2/loc.c (dwarf2_find_location_expression): Update.
(dwarf2_compile_property_to_c): Update.
(dwarf2_compile_expr_to_ax): Add dwarf2_per_objfile parameter,
use text offset from objfile.
(locexpr_tracepoint_var_ref): Update.
(locexpr_generate_c_location): Update.
(loclist_describe_location): Update.
(loclist_tracepoint_var_ref): Update.
* dwarf2/compile.h (compile_dwarf_bounds_to_c): Add
dwarf2_per_objfile parameter.
* dwarf2/loc2c.c (do_compile_dwarf_expr_to_c): Likewise,
use text offset from objfile.
(compile_dwarf_expr_to_c): Add dwarf2_per_objfile parameter.
Change-Id: I56b01ba294733362a3562426a96d48ae051a776f
Evaluating DWARF expressions (such as location expressions) requires
knowing about the current objfile. For example, it may call functions
like dwarf2_fetch_die_loc_sect_off, which currently obtain the
dwarf2_per_objfile object it needs from the dwarf2_per_cu_data object.
However, since we are going to remove this
dwarf2_per_cu_data::dwarf2_per_objfile link, these functions will need
to obtain the current dwarf2_per_objfile by parmeter.
If we go up the stack, we see that the DWARF expression contexts
(dwarf_expr_context and the classes that derive from it) need to store
the dwarf2_per_objfile, to be able to pass it to those functions that
will need it.
This patch adds a constructor to all these dwarf_expr_context variants,
accepting a dwarf2_per_objfile parameter. This dwarf2_per_objfile
generally comes from a symbol baton created earlier.
For frame-related expressions, the dwarf2_per_objfile object must be
passed through the dwarf2_frame_cache object. This lead to the
dwarf2_frame_find_fde function returning (by parameter) a
dwarf2_per_objfile object. I then realized that this made the existing
"out_offset" parameter redundant. This offset is
`objfile->text_section_offset ()`, so it can be recomputed from the
dwarf2_per_objfile object at any time. I therefore opted to remove this
output parameter, as well as the offset field of dwarf2_frame_cache.
*Note*, there's one spot I'm particularly unsure about. In
dwarf_evaluate_loc_desc::push_dwarf_reg_entry_value, we would save and
overwrite the offset value in the context, along with a bunch of other
state. This is because we might be about to evaluate something in a
different CU that the current one. If the two CUs are in the same
objfile, then the text_offset is the same, as it's a property of the
objfile. However, if the two CUs are possibly in different objfiles,
then it means the text_offsets are different. It would also mean we
would need to save and restore the dwarf2_per_objfile in the context.
Is that even possible?
gdb/ChangeLog:
* dwarf2/expr.h (struct dwarf_expr_context)
<dwarf_expr_context>: Add dwarf2_per_objfile parameter.
<offset>: Remove.
<per_objfile>: New member.
* dwarf2/expr.c (dwarf_expr_context::dwarf_expr_context): Add
dwarf2_per_objfile parameter. Don't set offset, set
per_objfile.
(dwarf_expr_context::execute_stack_op): Use offset from objfile.
* dwarf2/frame.c (dwarf2_frame_find_fde): Return (by parameter)
a dwarf2_per_objfile object instead of an offset.
(class dwarf_expr_executor) <dwarf_expr_executor>: Add
constructor.
(execute_stack_op): Add dwarf2_per_objfile parameter, pass it
to dwarf2_expr_executor constructor. Don't set offset.
(dwarf2_fetch_cfa_info): Update.
(struct dwarf2_frame_cache) <text_offset>: Remove.
<per_objfile>: New field.
(dwarf2_frame_cache): Update.
(dwarf2_frame_prev_register): Update.
* dwarf2/loc.c (class dwarf_evaluate_loc_desc)
<dwarf_evaluate_loc_desc>: Add constructor.
(dwarf2_evaluate_loc_desc_full): Update.
(dwarf2_locexpr_baton_eval): Update.
(class symbol_needs_eval_context) <symbol_needs_eval_context>:
Add constructor.
(dwarf2_loc_desc_get_symbol_read_needs): Update.
Change-Id: I14df060669cc36ad04759f1708c6d7b1fda77727
Various DWARF callbacks expect to be able to fetch the objfile and / or
dwarf2_per_objfile from the DWARF CU object. However, this won't be
possible once sharing is implemented.
Because these objects are related to full symbols (e.g., they are used
to implement location expressions), they can simply store the
dwarf2_per_objfile they need.
This patch adds a per_objfile member to the various "baton" structures
and arranges to set this value when constructing the baton.
gdb/ChangeLog:
YYYY-MM-DD Tom Tromey <tom@tromey.com>
YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com>
* dwarf2/loc.c (struct piece_closure) <per_objfile>: New member.
(allocate_piece_closure): Set "per_objfile" member.
(dwarf2_find_location_expression, dwarf2_locexpr_baton_eval)
(locexpr_describe_location, loclist_describe_location): Use new
member.
* dwarf2/read.c (read_call_site_scope)
(mark_common_block_symbol_computed, attr_to_dynamic_prop)
(dwarf2_const_value_attr, dwarf2_fetch_die_loc_sect_off)
(fill_in_loclist_baton, dwarf2_symbol_mark_computed,
handle_data_member_location): Set per_objfile member.
* dwarf2/loc.h (struct dwarf2_locexpr_baton) <per_objfile>: New
member.
(struct dwarf2_loclist_baton) <per_objfile>: New member.
Change-Id: If3aaa6a0f544be86710157c3adb68fde24d80037
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
When evaluating a DWARF expression, the dynamic type resolution code
will pass in a buffer of bytes via the property_addr_info. However,
the DWARF expression evaluator will then proceed to read memory from
the inferior, even when the request could be filled from this buffer.
This, in turn, is a problem in some cases; and specifically when
trying to handle the Ada scenario of extracting a variable-length
value from a packed array. Here, the ordinary DWARF expression cannot
be directly evaluated, because the data may appear at some arbitrary
bit offset. So, it is unpacked into a staging area and then the
expression is evaluated -- using an address of 0.
This patch fixes the problem by arranging for the DWARF evaluator, in
this case, to prefer passed-in memory when possible. The type of the
buffer in the property_addr_info is changed to an array_view so that
bounds checking can be done.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_discrete_type_high_bound, ada_discrete_type_low)
(ada_value_primitive_packed_val): Update.
* ada-valprint.c (ada_value_print_1): Update.
* dwarf2/loc.c (evaluate_for_locexpr_baton): New struct.
(dwarf2_locexpr_baton_eval): Take a property_addr_info rather than
just an address. Use evaluate_for_locexpr_baton.
(dwarf2_evaluate_property): Update.
* dwarf2/loc.h (struct property_addr_info) <valaddr>: Now an
array_view.
* findvar.c (default_read_var_value): Update.
* gdbtypes.c (compute_variant_fields_inner)
(resolve_dynamic_type_internal): Update.
(resolve_dynamic_type): Change type of valaddr parameter.
* gdbtypes.h (resolve_dynamic_type): Update.
* valarith.c (value_subscripted_rvalue): Update.
* value.c (value_from_contents_and_address): Update.
Some DWARF expressions must be evaluated by first pushing the object
address onto the evaluation stack. This patch adds this ability.
This functionality is not used yet, but it will be used in a later
patch. This is split out for easier review and also because it
improved the patch series ordering.
gdb/ChangeLog
2020-04-24 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add
"push_initial_value" parameter.
(dwarf2_evaluate_property): Likewise.
* dwarf2/loc.h (dwarf2_evaluate_property): Update.
GDB throws the error 'Unrecognized DWARF opcode 0x02 at 2' when running
Info address command with the executable file compiled with -gdwarf-5 flag.
This patch fixes this error.
Tested by running the testsuite before and after the patch and there is
no increase in the number of test cases that fails. Tested with both
-gdwarf-4 and -gdwarf-5 flags. Also tested -gslit-dwarf along with
-gdwarf-4 as well as -gdwarf-5 flags. Used clang version 10.0.0.
This is the test case used-
void bar(int arr[], int l, int m, int r) {
int i, j, k, n1= m - l + 1, n2= r - m, L[n1], R[n2];
for (i = 0; i < n1; i++)
L[i] = arr[l + i];
for (j = 0; j < n2; j++)
R[j] = arr[m + 1+ j];
}
int main()
{
int arr[] = {12, 11};
bar(arr,0,1,2);
return 0;
}
clang -gdwarf-5 test.c -o test.out
gdb test.out
gdb> start
gdb> step
gdb> step
gdb> step
gdb> step
gdb> info address L
Symbol "L" is multi-location:
Range 0x7c04007902bc5084-0x67fb876440700: a complex DWARF expression:
0: DW_OP_breg16 1 [$rip]
Unrecognized DWARF opcode 0x02 at 2
gdb/ChangeLog:
2020-04-07 Nitika Achra <Nitika.Achra@amd.com>
* dwarf2/loc.c (loclist_describe_location): Call the function decode_debug_loclists_
addresses if DWARF version is 5 or more because DW_LLE_start* or DW_LLE_offset_pair
with DW_LLE_base_addressx are being emitted in DWARFv5.
Add the newly added kind DW_LOC_OFFSET_PAIR also.
The length of location description is an unsigned ULEB integer in DWARFv5 instead of
unsigned integer.
GDB throws the error '<error reading variable: dwarf2_find_location_
expression: Corrupted DWARF expression.>' while printing the variable
value with executable file compiled with -gdwarf-5 and -gdwarf-split
flags. This is because DW_LLE_start* or DW_LLE_offset_pair with
DW_LLE_base_addressx are being emitted in DWARFv5 location list instead of
DW_LLE_GNU*. This patch fixes this error.
Tested by running the testsuite before and after the patch and there is no
increase in the number of test cases that fails. Tested with both -gdwarf-4
and -gdwarf-5 flags. Also tested -gslit-dwarf along with -gdwarf-4 as well as
-gdwarf-5 flags. Used clang version 10.0.0. This is the test case used-
void bar(int arr[], int l, int m, int r) {
int i, j, k, n1= m - l + 1, n2= r - m, L[n1], R[n2];
for (i = 0; i < n1; i++)
L[i] = arr[l + i];
for (j = 0; j < n2; j++)
R[j] = arr[m + 1+ j];
}
int main()
{
int arr[] = {12, 11};
bar(arr,0,1,2);
return 0;
}
clang -gdwarf-5 -gsplit-dwarf test.c -o test.out
gdb test.out
gdb> start
gdb> step
gdb> step
gdb> step
gdb> step
gdb> p L[0]
dwarf2_find_location_expression: Corrupted DWARF expression.
gdb/ChangeLog:
2020-04-07 Nitika Achra <Nitika.Achra@amd.com>
* dwarf2/loc.c (enum debug_loc_kind): Add a new kind DEBUG_LOC_OFFSET_PAIR.
(dwarf2_find_location_expression): Call the function decode_debug_loclists_
addresses if DWARF version is 5 or more. DW_LLE_start* or DW_LLE_offset_pair
with DW_LLE_base_addressx are being emitted in DWARFv5 instead of DW_LLE_GNU*.
Add applicable base address if the entry is DW_LLE_offset_pair from DWO.
(decode_debug_loclists_addresses): Return DEBUG_LOC_OFFSET_PAIR instead of
DEBUG_LOC_START_END in case of DW_LLE_offset_pair.
While debugging another issue, I noticed that disassembling a DWARF
expression using DW_OP_const_type did not work.
disassemble_dwarf_expression was not properly decoding this operation.
This patch fixes the problem. Tested by re-debugging gdb.
I didn't write a test case because that seemed like overkill for
what's essentially a maintainer's helper.
The expression evaluator does decode this properly, so no other change
was needed.
gdb/ChangeLog
2020-04-03 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.c (disassemble_dwarf_expression) <DW_OP_const_type>:
Read constant block.
dwarf2_evaluate_property should not modify its "addr_stack"
parameter's contents. This patch makes this part of the API, by
marking it const.
gdb/ChangeLog
2020-03-20 Tom Tromey <tromey@adacore.com>
* dwarf2/loc.h (dwarf2_evaluate_property): Make "addr_stack"
const.
* dwarf2/loc.c (dwarf2_evaluate_property): Make "addr_stack"
const.
When using the executable from test-case gdb.ada/access_to_packed_array.exp
(read-in using -readnow) and printing the symbols using "maint print symbols",
we run into a segv:
...
$ gdb -readnow -batch access_to_packed_array/foo -ex "maint print symbols"
...
info: array (<>) of character; computed at runtime
ptr: range 0 .. 2147483647; computed at runtime
Aborted (core dumped)
...
What happens is that dwarf2_evaluate_property gets called and sets the local
frame variable to the current frame, which happens to be NULL. Subsequently
the PROP_LOCLIST handling code is executed, where get_frame_address_in_block
gets called with argument NULL, and the segv is triggered.
Fix this by handling a NULL frame in the PROP_LOCLIST handling code in
dwarf2_evaluate_property.
Build and reg-tested on x86_64-linux.
gdb/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* dwarf2/loc.c (dwarf2_evaluate_property): Handle NULL frame in
PROP_LOCLIST handling code.
gdb/testsuite/ChangeLog:
2020-03-11 Tom de Vries <tdevries@suse.de>
* gdb.ada/access_to_packed_array.exp: Test printing of expanded
symtabs.
I noticed that dwarf2_compile_expr_to_ax can be static. Nothing
outside of loc.c calls it.
gdb/ChangeLog
2020-02-22 Tom Tromey <tom@tromey.com>
* dwarf2/loc.h (dwarf2_compile_expr_to_ax): Don't declare.
* dwarf2/loc.c (dwarf2_compile_expr_to_ax): Now static.
call_site_find_chain returns a pointer that the caller must
deallocate. It seemed better here to return a unique_xmalloc_ptr
instead.
gdb/ChangeLog
2020-02-14 Tom Tromey <tromey@adacore.com>
* dwarf2/frame-tailcall.c (dwarf2_tailcall_sniffer_first):
Update.
* dwarf2/loc.h (call_site_find_chain): Return unique_xmalloc_ptr.
* dwarf2/loc.c (call_site_find_chain_1): Return
unique_xmalloc_ptr.
(call_site_find_chain): Likewise.
The type dwarf_expr_baton is unused and can be removed.
gdb/ChangeLog
2020-02-12 Tom Tromey <tom@tromey.com>
* dwarf2/loc.c (struct dwarf_expr_baton): Remove.
Change-Id: Id8342da31398b9b4b08f31be7c3d612e9590bbbf
dwarf_always_disassemble is only used in dwarf2/loc.c, so move the
definition and the command infrastructure to that file.
2020-02-08 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf_always_disassemble)
(show_dwarf_always_disassemble): Move to loc.c.
(_initialize_dwarf2_read): Move "always-disassemble" registration
to loc.c.
* dwarf2/read.h (dwarf_always_disassemble): Don't declare.
* dwarf2/loc.c (dwarf_always_disassemble): Move from read.c. Now
static.
(show_dwarf_always_disassemble): Move from read.c.
(_initialize_dwarf2loc): Move always-disassemble from read.c.
Change-Id: I33fb88112e98e583c3f4919d20e4d100f2ea0124
