| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
With trying to load a non-executable file into gdb, we run into PR26880:
...
$ gdb -q -batch test.c
"0x7ffc87bfc8d0s": not in executable format: \
file format not recognized
...
The problem is caused by using %ps in combination with the error function
(note that confusingly, it does work in combination with the warning
function).
Fix this by using plain "%s" instead.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-08-23 Tom de Vries <tdevries@suse.de>
PR gdb/26880
* gdb/exec.c (exec_file_attach): Use %s instead of %ps in call to
error function.
gdb/testsuite/ChangeLog:
2021-08-23 Tom de Vries <tdevries@suse.de>
PR gdb/26880
* gdb.base/non-executable.exp: New file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 6a33fa0efec5aa87230a84bcab3c097237dd7f90)
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 4d0754c5f572b01cf2fe6c8ab292adba83331cbc)
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 0057a7ee0d9 "[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 (79aabb7308c "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 79aabb7308c
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.
|
|
|
|
|
|
|
|
|
