Philippe Blain pointed out that the gdb documentation does not mention
that Pygments may be used for source highlighting. This patch updates
the docs to reflect how highlighting is actually done.
(cherry picked from commit 6a33fa0efe)
gdb/doc/ChangeLog
2021-08-12 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Output Styling): Mention Pygments.
In PR28004 the following warning / Internal error is reported:
...
$ gdb -q -batch \
-iex "set sysroot $(pwd -P)/repro" \
./repro/gdb \
./repro/core \
-ex bt
...
Program terminated with signal SIGABRT, Aborted.
#0 0x00007ff8fe8e5d22 in raise () from repro/usr/lib/libc.so.6
[Current thread is 1 (LWP 1762498)]
#1 0x00007ff8fe8cf862 in abort () from repro/usr/lib/libc.so.6
warning: (Internal error: pc 0x7ff8feb2c21d in read in psymtab, \
but not in symtab.)
warning: (Internal error: pc 0x7ff8feb2c218 in read in psymtab, \
but not in symtab.)
...
#2 0x00007ff8feb2c21e in __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold] (warning: (Internal error: pc 0x7ff8feb2c21d in read in \
psymtab, but not in symtab.)
) from repro/usr/lib/libstdc++.so.6
...
The warning is about the following:
- in find_pc_sect_compunit_symtab we try to find the address
(0x7ff8feb2c218 / 0x7ff8feb2c21d) in the symtabs.
- that fails, so we try again in the partial symtabs.
- we find a matching partial symtab
- however, the partial symtab has a full symtab, so
we should have found a matching symtab in the first step.
The addresses are:
...
(gdb) info sym 0x7ff8feb2c218
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] in \
section .text of repro/usr/lib/libstdc++.so.6
(gdb) info sym 0x7ff8feb2c21d
__gnu_debug::_Error_formatter::_M_error() const [clone .cold] + 5 in \
section .text of repro/usr/lib/libstdc++.so.6
...
which correspond to unrelocated addresses 0x9c218 and 0x9c21d:
...
$ nm -C repro/usr/lib/libstdc++.so.6.0.29 | grep 000000000009c218
000000000009c218 t __gnu_debug::_Error_formatter::_M_error() const \
[clone .cold]
...
which belong to function __gnu_debug::_Error_formatter::_M_error() in
/build/gcc/src/gcc/libstdc++-v3/src/c++11/debug.cc.
The partial symtab that is found for the addresses is instead the one for
/build/gcc/src/gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc, which is
incorrect.
This happens as follows.
The bitmap_allocator.cc CU has DW_AT_ranges at .debug_rnglist offset 0x4b50:
...
00004b50 0000000000000000 0000000000000056
00004b5a 00000000000a4790 00000000000a479c
00004b64 00000000000a47a0 00000000000a47ac
...
When reading the first range 0x0..0x56, it doesn't trigger the "start address
of zero" complaint here:
...
/* A not-uncommon case of bad debug info.
Don't pollute the addrmap with bad data. */
if (range_beginning + baseaddr == 0
&& !per_objfile->per_bfd->has_section_at_zero)
{
complaint (_(".debug_rnglists entry has start address of zero"
" [in module %s]"), objfile_name (objfile));
continue;
}
...
because baseaddr != 0, which seems incorrect given that when loading the
shared library individually in gdb (and consequently baseaddr == 0), we do see
the complaint.
Consequently, we run into this case in dwarf2_get_pc_bounds:
...
if (low == 0 && !per_objfile->per_bfd->has_section_at_zero)
return PC_BOUNDS_INVALID;
...
which then results in this code in process_psymtab_comp_unit_reader being
called with cu_bounds_kind == PC_BOUNDS_INVALID, which sets the set_addrmap
argument to 1:
...
scan_partial_symbols (first_die, &lowpc, &highpc,
cu_bounds_kind <= PC_BOUNDS_INVALID, cu);
...
and consequently, the CU addrmap gets build using address info from the
functions.
During that process, addrmap_set_empty is called with a range that includes
0x9c218 and 0x9c21d:
...
(gdb) p /x start
$7 = 0x9989c
(gdb) p /x end_inclusive
$8 = 0xb200d
...
but it's called for a function at DIE 0x54153 with DW_AT_ranges at 0x40ae:
...
000040ae 00000000000b1ee0 00000000000b200e
000040b9 000000000009989c 00000000000998c4
000040c3 <End of list>
...
and neither range includes 0x9c218 and 0x9c21d.
This is caused by this code in partial_die_info::read:
...
if (dwarf2_ranges_read (ranges_offset, &lowpc, &highpc, cu,
nullptr, tag))
has_pc_info = 1;
...
which pretends that the function is located at addresses 0x9989c..0xb200d,
which is indeed not the case.
This patch fixes the first problem encountered: fix the "start address of
zero" complaint warning by removing the baseaddr part from the condition.
Same for dwarf2_ranges_process.
The effect is that:
- the complaint is triggered, and
- the warning / Internal error is no longer triggered.
This does not fix the observed problem in partial_die_info::read, which is
filed as PR28200.
Tested on x86_64-linux.
Co-Authored-By: Simon Marchi <simon.marchi@polymtl.ca>
gdb/ChangeLog:
2021-08-06 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/28004
* dwarf2/read.c (dwarf2_rnglists_process, dwarf2_ranges_process):
Fix zero address complaint.
gdb/testsuite/ChangeLog:
2021-08-06 Simon Marchi <simon.marchi@polymtl.ca>
Tom de Vries <tdevries@suse.de>
PR symtab/28004
* gdb.dwarf2/dw2-zero-range-shlib.c: New test.
* gdb.dwarf2/dw2-zero-range.c: New test.
* gdb.dwarf2/dw2-zero-range.exp: New file.
PR varobj/28131 points out a crash in the varobj deletion code. It
took a while to reproduce this, but essentially what happens is that a
top-level varobj deletes its root object, then deletes the "dynamic"
object. However, deletion of the dynamic object may cause
~py_varobj_iter to run, which in turn uses gdbpy_enter_varobj:
gdbpy_enter_varobj::gdbpy_enter_varobj (const struct varobj *var)
: gdbpy_enter (var->root->exp->gdbarch, var->root->exp->language_defn)
{
}
However, because var->root has already been destroyed, this is
invalid.
I've added a new test case. This doesn't reliably crash, but the
problem can easily be seen under valgrind (and, I presume, with ASAN,
though I did not try this).
Tested on x86-64 Fedora 32. I also propose putting this on the GDB 11
branch, with a suitable ChangeLog entry of course.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28131
(cherry picked from commit 4d0754c5f5)
gdb/ChangeLog
2021-08-02 Tom Tromey <tromey@adacore.com>
PR varobj/28131
* varobj.c (~varobj): Delete 'dynamic' before 'root'.
gdb/testsuite/ChangeLog
2021-08-02 Tom Tromey <tromey@adacore.com>
PR varobj/28131
* gdb.python/py-mi-var-info-path-expression.exp: Add regression
test.
When printing the fields of a register that is of a custom struct type,
the "unpack_bits_as_long ()" function is used:
do_val_print (...)
cp_print_value_fields (...)
value_field_bitfield (...)
unpack_value_bitfield (...)
unpack_bits_as_long (...)
This function may sign-extend the extracted field while returning it:
val >>= lsbcount;
if (...)
{
valmask = (((ULONGEST) 1) << bitsize) - 1;
val &= valmask;
if (!field_type->is_unsigned ())
if (val & (valmask ^ (valmask >> 1)))
val |= ~valmask;
}
return val;
lsbcount: Number of lower bits to get rid of.
bitsize: The bit length of the field to be extracted.
val: The register value.
field_type: The type of field that is being handled.
While the logic here is correct, there is a problem when it is
handling "field_type"s of "boolean". Those types are NOT marked
as "unsigned" and therefore they end up being sign extended.
Although this is not a problem for "false" (0), it definitely
causes trouble for "true".
This patch constructs the builtin boolean type as such that it is
marked as an "unsigned" entity.
The issue tackled here was first encountered for arc-elf32 target
running on an x86_64 machine. The unit-test introduced in this change
has passed for all the targets (--enable-targets=all) running on the
same x86_64 host.
gdb/ChangeLog:
PR gdb/28104
* gdbtypes.c (gdbtypes_post_init): Use
"arch_boolean_type (..., unsigned=1, ...) to construct
"boolean".
cp-valprint.c (test_print_flags): New.
(_initialize_cp_valprint): Run the "test_print_flags" unit-test.
With trunk gcc (12.0) we're running into a -Werror=nonnull-compare build
breaker in gdb, which caused a broader review of the usage of the nonnull
attribute.
The current conclusion is that it's best to disable this. This is explained
at length in the gdbsupport/common-defs.h comment.
Tested by building with trunk gcc.
gdbsupport/ChangeLog:
2021-07-30 Tom de Vries <tdevries@suse.de>
* common-defs.h (ATTRIBUTE_NONNULL): Disable.
[ 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-28 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (attr_to_dynamic_prop): Handle DW_FORM_data16.
With gcc 8.5.0 I run into:
...
(gdb) print bad^M
$2 = (0 => 0 <repeats 25 times>)^M
(gdb) FAIL: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...
while with gcc 9.3.1 we have instead:
...
(gdb) print bad^M
$2 = (false <repeats 196 times>)^M
(gdb) PASS: gdb.ada/big_packed_array.exp: scenario=minimal: print bad
...
This is caused by gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101643 "[debug, ada] packed array
not described as packed".
Fix by marking this as XFAIL.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-07-27 Tom de Vries <tdevries@suse.de>
PR testsuite/26904
* gdb/testsuite/gdb.ada/big_packed_array.exp: Add xfail.
With gcc 7.5.0, I run into:
...
(gdb) print objects^M
$1 = ((tag => object, values => ()), (tag => unused))^M
(gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...
while with gcc 8.5.0 we have:
...
(gdb) print objects^M
$1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
(gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...
This is due to a gcc PR, which I've filed at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101633 "Bug 101633 - [debug]
DW_TAG_subrange_type missing DW_AT_upper_bound".
Fix by marking this and related FAILs as XFAIL.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-07-27 Tom de Vries <tdevries@suse.de>
PR testsuite/26903
* gdb/testsuite/gdb.ada/array_of_variant.exp: Add xfails.
Generated from sys/sys/syscall.h revision 1.319.
We can safely remove the _lwp_gettid syscall, which was never exposed
in libc and never made it into a release.
gdb/ChangeLog:
2021-07-26 Frederic Cambus <fred@statdns.com>
* syscalls/netbsd.xml: Regenerate.
The "val_print_type_code_flags ()" function is responsible for
extraction of fields for "flags" data type. These data types are
used when describing a custom register type in a target description
XML. The logic used for the extraction though is not sound:
unsigned field_len = TYPE_FIELD_BITSIZE (type, field);
ULONGEST field_val
= val >> (TYPE_FIELD_BITPOS (type, field) - field_len + 1);
TYPE_FIELD_BITSIZE: The bit length of the field to be extracted.
TYPE_FIELD_BITPOS: The starting position of the field; 0 is LSB.
val: The register value.
Imagine you have a field that starts at position 1 and its length
is 4 bits. According to the third line of the code snippet the
shifting right would become "val >> -2", or "val >> 0xfff...fe"
to be precise. That will result in a "field_val" of 0.
The correct extraction should be:
ULONGEST field_val = val >> TYPE_FIELD_BITPOS (type, field);
The rest of the algorithm that masks out the higher bits is OK.
gdb/ChangeLog:
2021-07-26 Shahab Vahedi <shahab@synopsys.com>
Simon Marchi <simon.marchi@efficios.com>
PR gdb/28103
* valprint.c (val_print_type_code_flags): Merely shift the VAL
to the right to get rid of the lower bits.
(test_print_flags): New.
(_initialize_valprint): Invoke the "test_print_flags" as a unit-test.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
As reported in PR gdb/28076 [1], passing no condition argument to the
-break-condition command (e.g.: "-break-condition 2") should clear the
condition for breakpoint 2, just like CLI's "condition 2", but instead
an error message is returned:
^error,msg="-break-condition: Missing the <number> and/or <expr> argument"
The current implementation of the -break-condition command's argument
handling (79aabb7308 "gdb/mi: add a '--force' flag to the
'-break-condition' command") was done according to the documentation,
where the condition argument seemed mandatory. However, the
-break-condition command originally (i.e. before the 79aabb7308
patch) used the CLI's "cond" command, and back then not passing a
condition argument was clearing out the condition. So, this is a
regression in terms of the behavior.
Fix the argument handling of the -break-condition command to allow not
having a condition argument, and also update the document to make the
behavior clear. Also add test cases to test the scenarios which were
previously not covered.
[1] https://sourceware.org/bugzilla/show_bug.cgi?id=28076
gdb/ChangeLog:
2021-07-26 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
PR gdb/28076
* mi/mi-cmd-break.c (mi_cmd_break_condition): Handle the case
of having no condition argument.
gdb/doc/ChangeLog:
2021-07-26 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
PR gdb/28076
* gdb.texinfo (GDB/MI Breakpoint Commands): Mention clearing
the condition in the -break-condition command.
gdb/testsuite/ChangeLog:
2021-07-26 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
PR gdb/28076
* gdb.mi/mi-break.exp: Add more tests to check clearing the
breakpoint condition.
When running test-case gdb.ada/formatted_ref.exp with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4 we run into:
...
(gdb) print/x s^M
No definition of "s" in current context.^M
(gdb) FAIL: gdb.ada/formatted_ref.exp: print/x s
...
which is caused by "runto defs.adb:20" taking us to defs__struct1IP:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402cfd: defs.adb:20. (2 locations)^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs__struct1IP () at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
(gdb) print s1'access^M
...
instead of the expected defs.f1:
...
(gdb) break defs.adb:20^M
Breakpoint 1 at 0x402d0e: file defs.adb, line 20.^M
(gdb) run ^M
Starting program: formatted_ref ^M
^M
Breakpoint 1, defs.f1 (s=...) at defs.adb:20^M
20 return s.x; -- Set breakpoint marker here.^M
...
This is caused by incorrect line info due to gcc PR 101575 - "[gcc-11,
-gdwarf-4] Missing .file <n> directive causes invalid line info".
Fix this by when landing in defs__struct1IP:
- xfailing the runto, and
- issuing a continue to land in defs.f1.
Likewise in a few other test-cases.
Tested on x86_64-linux, with:
- system gcc.
- gcc-11 and target boards unix/gdb:debug_flags=-gdwarf-4 and
unix/gdb:debug_flags=-gdwarf-5.
gdb/testsuite/ChangeLog:
2021-07-22 Tom de Vries <tdevries@suse.de>
* gdb.ada/formatted_ref.exp: Add xfail for PR gcc/101575.
* gdb.ada/iwide.exp: Same.
* gdb.ada/pkd_arr_elem.exp: Same.
When running test-case gdb.cp/step-and-next-inline.exp with gcc-11, I run
into:
...
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 1 \
(PRMS symtab/25507)
FAIL: gdb.cp/step-and-next-inline.exp: no_header: next step 2
KPASS: gdb.cp/step-and-next-inline.exp: no_header: next step 3 \
(PRMS symtab/25507)
...
[ Note that I get the same result with gcc-11 and target board
unix/gdb:debug_flags=-gdwarf-4, so this is not a dwarf 4 vs 5 issue. ]
With gcc-10, I have this trace:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
40 if (t->x != i)
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with gcc-11, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601038 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
43 return x;
53 && TREE_TYPE (t).z != 2
43 return x;
54 && TREE_TYPE (t).z != 3)
43 return x;
main () at step-and-next-inline.cc:65
65 return 0;
...
and with clang-10, I have instead:
...
64 get_alias_set (&xx);
get_alias_set (t=0x601034 <xx>) at step-and-next-inline.cc:51
51 if (t != NULL
52 && TREE_TYPE (t).z != 1
53 && TREE_TYPE (t).z != 2
54 && TREE_TYPE (t).z != 3)
51 if (t != NULL
57 }
main () at step-and-next-inline.cc:65
65 return 0;
...
The test-case tries to verify that we don't step into inlined function
tree_check (lines 40-43) (so, with the clang trace we get that right).
The test-case then tries to kfail the problems when using gcc, but this is
done in such a way that the testing still gets out of sync after a failure.
That is: the "next step 2" check that is supposed to match
"TREE_TYPE (t).z != 2" is actually matching "TREE_TYPE (t).z != 1":
...
(gdb) next^M
52 && TREE_TYPE (t).z != 1^M
(gdb) PASS: gdb.cp/step-and-next-inline.exp: no_header: next step 2
...
Fix this by issuing extra nexts to arrive at the required lines.
Tested on x86_64-linux, with gcc-8, gcc-9, gcc-10, gcc-11, clang-8, clang-10
and clang-12.
gdb/testsuite/ChangeLog:
2021-07-22 Tom de Vries <tdevries@suse.de>
* gdb.cp/step-and-next-inline.cc (tree_check, get_alias_set, main):
Tag closing brace with comment.
* gdb.cp/step-and-next-inline.h: Update to keep identical with
step-and-next-inline.cc.
* gdb.cp/step-and-next-inline.exp: Issue extra next when required.
When running test-case gdb.base/ptype-offsets.exp with gcc-11 (with -gdwarf-5
default) or gcc-10 with target board unix/gdb:debug_flags=-gdwarf-5 we run
into this regression:
...
(gdb) ptype/o static_member^M
/* offset | size */ type = struct static_member {^M
- static static_member Empty;^M
/* 0 | 4 */ int abc;^M
^M
/* total size (bytes): 4 */^M
}^M
-(gdb) PASS: gdb.base/ptype-offsets.exp: ptype/o static_member
+(gdb) FAIL: gdb.base/ptype-offsets.exp: ptype/o static_member
...
This is caused by missing debug info, which I filed as gcc PR101452 - "[debug,
dwarf-5] undefined static member removed by
-feliminate-unused-debug-symbols".
It's not clear yet whether this is a bug or a feature, but work around this in
the test-cases by:
- defining the static member
- adding additional_flags=-fno-eliminate-unused-debug-types.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-07-21 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gcc_major_version): New proc.
* gdb.base/ptype-offsets.cc: Define static member static_member::Empty.
* gdb.cp/templates.exp: Define static member using -DGCC_BUG.
* gdb.cp/m-static.exp: Add
additional_flags=-fno-eliminate-unused-debug-types.
* gdb.cp/pr-574.exp: Same.
* gdb.cp/pr9167.exp: Same.
With gcc-11 we run into:
...
(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)
...
This is due to PR exp/20991 - "__int128 type support". Mark this and similar
FAILs as KFAIL.
Also mark this FAIL:
....
(gdb) print pa_ptr(3)^M
cannot subscript or call something of type `foo__packed_array_ptr'^M
(gdb) FAIL: gdb.ada/arrayptr.exp: scenario=minimal: print pa_ptr(3)
...
as a KFAIL for PR ada/28115 - "Support packed array encoded as
DW_TAG_subrange_type".
Tested on x86_64-linux, with gcc-10 and gcc-11.
gdb/testsuite/ChangeLog:
2021-07-21 Tom de Vries <tdevries@suse.de>
* gdb.ada/arrayptr.exp: Add KFAILs for PR20991 and PR28115.
* gdb.ada/exprs.exp: Add KFAILs for PR20991.
* gdb.ada/packed_array_assign.exp: Same.
When the architecture supports memory tagging, we handle
pointer/reference types in a special way, so we can validate tags and
show mismatches.
Unfortunately, the currently implementation errors out when the user
prints non-address values: composite types, floats, references, member
functions and other things.
Vector registers:
(gdb) p $v0
Value can't be converted to integer.
Non-existent internal variables:
(gdb) p $foo
Value can't be converted to integer.
The same happens for complex types and printing struct/union types.
There are a few problems here.
The first one is that after print_command_1 evaluates the expression
to print, the tag validation code call value_as_address
unconditionally, without making sure we have have a suitable type
where it makes to sense to call it. That results in value_as_address
(if it isn't given a pointer-like type) trying to treat the value as
an integer and convert it to an address, which #1 - doesn't make sense
(i.e., no sense in validating tags after "print 1"), and throws for
non-integer-convertible types. We fix this by making sure we have a
pointer or reference type first, and only if so then proceed to check
if the address-like value has tags.
The second is that we're calling value_as_address even if we have an
optimized out or unavailable value, which throws, because the value's
contents aren't fully accessible/readable. This error currently
escapes out and aborts the print. This case is fixed by checking for
optimized out / unavailable explicitly.
Third, the tag checking process does not gracefully handle exceptions.
If any exception is thrown from the tag validation code, we abort the
print. E.g., the target may fail to access tags via a running thread.
Or the needed /proc files aren't available. Or some other untold
reason. This is a bit too rigid. This commit changes print_command_1
to catch errors, print them, and still continue with the normal
expression printing path instead of erroring out and printing nothing
useful.
With this patch, printing works correctly again:
(gdb) p $v0
$1 = {d = {f = {2.0546950501119882e-81, 2.0546950501119882e-81}, u = {3399988123389603631, 3399988123389603631}, s = {
3399988123389603631, 3399988123389603631}}, s = {f = {1.59329203e-10, 1.59329203e-10, 1.59329203e-10, 1.59329203e-10}, u = {
791621423, 791621423, 791621423, 791621423}, s = {791621423, 791621423, 791621423, 791621423}}, h = {bf = {1.592e-10,
1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10, 1.592e-10}, f = {0.11224, 0.11224, 0.11224, 0.11224, 0.11224,
0.11224, 0.11224, 0.11224}, u = {12079, 12079, 12079, 12079, 12079, 12079, 12079, 12079}, s = {12079, 12079, 12079, 12079,
12079, 12079, 12079, 12079}}, b = {u = {47 <repeats 16 times>}, s = {47 <repeats 16 times>}}, q = {u = {
62718710765820030520700417840365121327}, s = {62718710765820030520700417840365121327}}}
(gdb) p $foo
$2 = void
(gdb) p 2 + 2i
$3 = 2 + 2i
gdb/ChangeLog
2021-07-20 Luis Machado <luis.machado@linaro.org>
Pedro Alves <pedro@palves.net>
PR gdb/28110
* gdbarch.sh: Updated documentation for gdbarch_tagged_address_p.
* gdbarch.h: Regenerate.
* printcmd.c (should_validate_memtags): Reorder comparisons and only
validate tags for pointer and reference types. Skip validation of
optimized out or unavailable values.
(print_command_1): Guard call memory tagging validation code with
a try/catch block.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: I82bf00ac88d23553b3f7563c9872dfa6ca1f2207
PR gdb/28093 points out that gdb crashes when language is set to
"unknown" and expression parsing is attempted. At first I thought
this was a regression due to the expression rewrite, but it turns out
that older versions crash as well.
This patch avoids the crash by changing the default expression parser
to throw an exception. I think this is preferable -- the current
behavior of silently doing nothing does not really make sense.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28093
(cherry picked from commit dcd482c1b7)
gdb/ChangeLog
2021-07-19 Tom Tromey <tromey@adacore.com>
PR gdb/28093
* language.c (auto_or_unknown_language::parser): Call error.
gdb/testsuite/ChangeLog
2021-07-19 Tom Tromey <tromey@adacore.com>
PR gdb/28093
* gdb.base/langs.exp: Add tests.
