| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On aarch64-linux, I run into:
...
Breakpoint 2, pck.inspect (obj=0x430eb0 \
<system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
17 procedure Inspect (Obj: access Top_T'Class) is^M
(gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
...
while on x86_64-linux, I see:
...
Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
19 null;^M
(gdb) PASS: gdb.ada/access_tagged_param.exp: continue
...
Note the different line numbers, 17 vs 19.
The difference comes from the gdbarch_skip_prologue implementation.
The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
back to the architecture-specific prologue analyzer, which correctly skips
past the prologue, to address 0x4022f7:
...
00000000004022ec <pck__inspect>:
4022ec: 55 push %rbp
4022ed: 48 89 e5 mov %rsp,%rbp
4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4022f4: 89 75 f4 mov %esi,-0xc(%rbp)
4022f7: 90 nop
4022f8: 90 nop
4022f9: 5d pop %rbp
4022fa: c3 ret
...
The aarch64_skip_prologue implementation does use gcc line numbers, which are:
...
File name Line number Starting address View Stmt
pck.adb 17 0x402580 x
pck.adb 17 0x402580 1 x
pck.adb 19 0x40258c x
pck.adb 20 0x402590 x
...
and which are represented like this internally in gdb:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
0 17 0x0000000000402580 Y
1 17 0x0000000000402580 Y
2 19 0x000000000040258c Y
3 20 0x0000000000402590 Y
4 END 0x00000000004025a0 Y
...
The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
the actual end of the prologue is at 0x40258c:
...
0000000000402580 <pck__inspect>:
402580: d10043ff sub sp, sp, #0x10
402584: f90007e0 str x0, [sp, #8]
402588: b90007e1 str w1, [sp, #4]
40258c: d503201f nop
402590: d503201f nop
402594: 910043ff add sp, sp, #0x10
402598: d65f03c0 ret
40259c: d503201f nop
...
Note that the architecture-specific prologue analyzer would have gotten this
right:
...
(gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
$2 = 0x40258c
...
Fix the FAIL by making the test-case more robust against problems in prologue
skipping, by setting the breakpoint on line 19 instead.
Likewise in a few similar test-cases.
Tested on x86_64-linux and aarch64-linux.
|
|
On openSUSE Tumbleweed (using glibc 2.36), I run into:
...
(gdb) print /d (int) munmap (4198400, 4096)^M
Invalid cast.^M
(gdb) FAIL: gdb.base/break-main-file-remove-fail.exp: cmdline: \
get integer valueof "(int) munmap (4198400, 4096)"
...
The problem is that after starting the executable, the symbol has type
"void (*) (void)":
...
(gdb) p munmap
$1 = {<text variable, no debug info>} 0x401030 <munmap@plt>
(gdb) start
...
(gdb) p munmap
$2 = {void (void)} 0x7ffff7feb9a0 <__GI_munmap>
...
which causes the "Invalid cast" error.
Looking at the debug info for glibc for symbol __GI_munmap:
...
<0><189683>: Abbrev Number: 1 (DW_TAG_compile_unit)
<189691> DW_AT_name : ../sysdeps/unix/syscall-template.S
<189699> DW_AT_producer : GNU AS 2.39.0
<1><1896ae>: Abbrev Number: 2 (DW_TAG_subprogram)
<1896af> DW_AT_name : __GI___munmap
<1896b3> DW_AT_external : 1
<1896b4> DW_AT_low_pc : 0x10cad0
<1896bc> DW_AT_high_pc : 37
...
that's probably caused by this bit (or similar bits for other munmap aliases).
This is fixed in gas on trunk by commit 5578fbf672e ("GAS: Add a return type
tag to DWARF DIEs generated for function symbols").
Work around this (for say gas 2.39) by explicitly specifying the prototype for
munmap.
Likewise for getpid in a couple of other test-cases.
Tested on x86_64-linux.
|
|
When running test-case gdb.cp/cpexprs-debug-types.exp on target board
cc-with-debug-names/gdb:debug_flags=-gdwarf-5, we get an executable with
a .debug_names section, but no .debug_types section. For dwarf-5, the TUs
are no longer put in a separate unit, but instead they're put in the
.debug_info section.
When loading the executable, the .debug_names section is silently ignored
because of this check in dwarf2_read_debug_names:
...
if (map->tu_count != 0)
{
/* We can only handle a single .debug_types when we have an
index. */
if (per_bfd->types.size () != 1)
return false;
...
which triggers because per_bfd->types.size () == 0.
The intention of the check is to make sure we don't have more that one
.debug_types section, as can happen in a object file (see PR12984):
...
$ grep "\.debug_types" 11.s
.section .debug_types,"G",@progbits,wt.75c042c23a9a07ee,comdat
.section .debug_types,"G",@progbits,wt.c59c413bf50a4607,comdat
...
Fix this by:
- changing the check condition to "per_bfd->types.size () > 1", and
- handling per_bfd->types.size () == 0.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29385
|
|
Add test-case gdb.dwarf2/debug-names-bad-cu-index.exp, a regression test for
commit 2fe9a3c41fa ("[gdb/symtab] Fix bad compile unit index complaint").
Tested on x86_64-linux.
|
|
Add a test-case gdb.dwarf2/debug-names-tu.exp, that uses the dwarf assembler
to specify a .debug_names index with the TU list referring to a TU from the
.debug_types section.
This is intended to produce something similar to:
...
$ gcc -g -fdebug-types-section ~/hello.c -gdwarf-4
$ gdb-add-index -dwarf-5 a.out
...
Tested on x86_64-linux.
|
|
PR mi/10347 points out that using interpreter-exec inside of a
"define" command will crash gdb. The bug here is that
gdb_setup_readline doesn't check for the case where instream==nullptr.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=10347
|
|
PR mi/15811 points out that "source"ing a file that uses
interpreter-exec will put gdb in a weird state, where the CLI stops
working. The bug is that tui_interp::suspend does not unregister the
event file descriptor.
The test case is from Andrew Burgess.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15811
|
|
First, some background on the RISC-V registers fflags, frm, and fcsr.
These three registers all relate to the floating-point status and
control mechanism on RISC-V. The fcsr is the floatint-point control
status register, and consists of two parts, the flags (bits 0 to 4)
and the rounding-mode (bits 5 to 7).
The fcsr register is just one of many control/status registers (or
CSRs) available on RISC-V. The fflags and frm registers are also
CSRs. These CSRs are aliases for the relevant parts of the fcsr
register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is
an alias for bits 5 to 7 of fcsr.
This means that a user can change the floating-point rounding mode
either, by writing a complete new value into fcsr, or by writing just
the rounding mode into frm.
How this impacts on GDB is like this: a target description could,
legitimately include all three registers, fcsr, fflags, and frm. The
QEMU target currently does this, and this makes sense. The target is
emulating the complete system, and has all three CSRs available, so
why not tell GDB about this.
In contrast, the RISC-V native Linux target only has access to the
fcsr. This is because the ptrace data structure that the kernel uses
for reading and writing floating point state only contains a copy of
the fcsr, after all, this one field really contains both the fflags
and frm fields, so why carry around duplicate data.
So, we might expect that the target description for the RISC-V native
Linux GDB would only contain the fcsr register. Unfortunately, this
is not the case. The RISC-V native Linux target uses GDB's builtin
target descriptions by calling riscv_lookup_target_description, this
will then add an fpu feature from gdb/features/riscv, either
32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features
include an entry for fcsr, fflags, and frm. This means that GDB
expects the target to handle reading and writing these registers. And
the RISC-V native Linux target currently doesn't.
In riscv_linux_nat_target::store_registers and
riscv_linux_nat_target::fetch_registers only the fcsr register is
handled, this means that, for RISC-V native Linux, the fflags and frm
registers always show up as <unavailable> - they are present in the
target description, but the target doesn't know how to access the
registers.
A final complication relating to these floating pointer CSRs is which
target description feature the registers appear in.
These registers are CSRs, so it would seem sensible that these
registers should appear in the CSR target description feature.
However, when I first added RISC-V target description support, I was
using a RISC-V simulator that didn't support any CSRs other than the
floating point related ones. This simulator bundled all the float
related CSRs into the fpu target feature. This didn't feel completely
unreasonable to me, and so I had GDB check for these registers in
either target feature.
In this commit I make some changes relating to how GDB handles the
three floating point CSR:
1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This
means that the default RISC-V target description (which RISC-V native
FreeBSD), and the target descriptions created for RISC-V native Linux,
will not include these registers. There's nothing stopping some other
target (e.g. QEMU) from continuing to include all three of these CSRs,
the code in riscv-tdep.c continues to check for all three of these
registers, and will handle them correctly if they are present.
2. If a target supplied fcsr, but does not supply fflags and/or frm,
then RISC-V GDB will now create two pseudo registers in order to
emulate the two missing CSRs. These new pseudo-registers do the
obvious thing of just reading and writing the fcsr register.
3. With the new pseudo-registers we can no longer make use of the GDB
register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM.
These will be the numbers used if the target supplies the registers in
its target description, but, if GDB falls back to using
pseudo-registers, then new, unique numbers will be used. To handle
this I've added riscv_gdbarch_tdep::fflags_regnum and
riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to
compare against these fields.
When adding the pseudo-register support, it is important that the
pseudo-register numbers are calculated after the call to
tdesc_use_registers. This is because we don't know the total number
of physical registers until after this call, and the psuedo-register
numbers must follow on from the real (target supplied) registers.
I've updated some tests to include more testing of the fflags and frm
registers, as well as adding a new test.
|
|
On RISC-V the FCSR (float control/status register) is split into two
parts, FFLAGS (the flags) and FRM (the rounding mode). Both of these
two fields are part of the FCSR register, but can also be accessed as
separate registers in their own right. And so, we have three separate
registers, $fflags, $frm, and $fcsr, with the last of these being the
combination of the first two.
Here's how the bits of FCSR are split between FRM and FFLAGS:
,--------- FFLAGS
|---|
76543210 <----- FCSR
|-|
'--------------FRM
Here's how GDB currently displays these registers:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Notice the 'RD' field which is present in both $fflags and $fcsr.
This field contains the value of the FRM field, which makes sense when
displaying the $fcsr, but makes no sense when displaying $fflags, as
the $fflags doesn't include the FRM field.
Additionally, the $fcsr already includes an FRM field, so the
information in 'RD' is duplicated. Consider this:
(gdb) set $frm = 0x3
(gdb) info registers $fflags $frm $fcsr │
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x3 FRM:3 [RUP (Round up towards +INF)]
fcsr 0x60 RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
See how the 'RD' field in $fflags still displays 0, while the 'RD' and
'FRM' fields in $fcsr show the same information.
The first change I propose in this commit is to remove the 'RD'
field. After this change the output now looks like this:
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]
fcsr 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]
Next, I spotted that the text that goes along with the 'FRM' field was
not wrapped in the i18n markers for internationalisation, so I added
those.
Next, I spotted that:
(gdb) set $frm=0x7
(gdb) info registers $fflags $frm $fcsr
fflags 0x0 RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
frm 0x7 FRM:3 [RUP (Round up towards +INF)]
fcsr 0xe0 RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]
Notice that despite being a 3-bit field, FRM masks to 2-bits.
Checking the manual I can see that the FRM field is 3-bits, and is
defined for all 8 values. That GDB masks to 2-bits is just a bug I
think, so I've fixed this.
Finally, the 'FRM' text for value 0x7 is wrong. Currently we use the
text 'dynamic rounding mode' for value 0x7. However, this is not
really correct.
A RISC-V instruction can either encode the rounding mode within the
instruction, or a RISC-V instruction can choose to use a global,
dynamic rounding mode.
So, for the rounding-mode field of an _instruction_ the value 0x7
indicates "dynamic round mode", the instruction should defer to the
rounding mode held in the FRM field of the $fcsr.
But it makes no sense for the FRM of $fcsr to itself be set to
0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
Control and Status Register" of the RISC-V manual, says that a value
of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
_its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
then an illegal instruction exception is raised.
And so, I propose changing the text for value 0x7 of the FRM field to
be "INVALID[7] (Dynamic rounding mode)". We already use the text
"INVALID[5]" and "INVALID[6]" for the two other invalid fields,
however, I think adding the extra "Dynamic round mode" hint might be
helpful.
I've added a new test that uses 'info registers' to check what GDB
prints for the three registers related to this patch. There is one
slight oddity with this test - for the fflags and frm registers, the
test accepts both the "normal" output (as described above), but also
allows these registers to be reported as '<unavailable>'.
The reason why I accept <unavailable> is that currently, the RISC-V,
native Linux target advertises these registers in its target
description, but then doesn't support reading or writing of these
registers, this results in the registers being reported as
unavailable.
A later patch in this series will address this issue, and will remove
this check for <unavailable>.
|
|
The following GDB behavior was also reported as a GDB bug in
https://sourceware.org/bugzilla/show_bug.cgi?id=28396
I will reiterate the problem a bit and give some more information here.
This patch closes the above mentioned bug.
The DWARF 5 standard 2.23 'Template Parameters' reads:
A template type parameter is represented by a debugging information
entry with the tag DW_TAG_template_type_parameter. A template value
parameter is represented by a debugging information entry with the tag
DW_TAG_template_value_parameter. The actual template parameter entries
appear in the same order as the corresponding template formal
parameter declarations in the source progam.
A type or value parameter entry may have a DW_AT_name attribute, whose
value is a null-terminated string containing the name of the
corresponding formal parameter.
So the DW_AT_name attribute for DW_TAG_template_type_parameter and
DW_TAG_template_value_parameter is optional.
Within GDB, creating a new symbol from some read DIE usually requires the
presence of a DW_AT_name for the DIE (an exception here is the case of
unnamed namespaces or the existence of a linkage name).
This patch makes the presence of the DW_AT_name for template value/type
tags optional, similar to the unnamed namespaces.
For unnamed namespaces dwarf2_name simply returns the constant string
CP_ANONYMOUS_NAMESPACE_STR '(anonymous namespace)'. For template tags a
case was added to the switch statement calling the
unnamed_template_tag_name helper. Within the scope of parent which
the template parameter is a child of, the helper counts the position
of the template tag within the unnamed template tags and returns
'<unnamedNUMBER>' where NUMBER is its position. This way we end up with
unique names within the respective scope of the function/class/struct
(these are the only currenltly supported template kinds within GDB and
usually the compilers) where we discovered the template tags in.
While I do not know of a way to bring GCC to emit template tags without
names there is one for clang/icpx. Consider the following example
template<typename A, typename B, typename C>
class Foo {};
template<typename, typename B, typename>
class Foo;
int main () {
Foo<double, int, float> f;
return 0;
}
The forward declaration for 'Foo' with the missing template type names
'A' and 'C' makes clang emit a bunch of template tags without names:
...
<2><43>: Abbrev Number: 3 (DW_TAG_variable)
<44> DW_AT_location : 2 byte block: 91 78 (DW_OP_fbreg: -8)
<47> DW_AT_name : (indirect string, offset: 0x63): f
<4b> DW_AT_decl_file : 1
<4c> DW_AT_decl_line : 8
<4d> DW_AT_type : <0x59>
...
<1><59>: Abbrev Number: 5 (DW_TAG_class_type)
<5a> DW_AT_calling_convention: 5 (pass by value)
<5b> DW_AT_name : (indirect string, offset: 0x74): Foo<double, int, float>
<5f> DW_AT_byte_size : 1
<60> DW_AT_decl_file : 1
<61> DW_AT_decl_line : 2
<2><62>: Abbrev Number: 6 (DW_TAG_template_type_param)
<63> DW_AT_type : <0x76>
<2><67>: Abbrev Number: 7 (DW_TAG_template_type_param)
<68> DW_AT_type : <0x52>
<6c> DW_AT_name : (indirect string, offset: 0x6c): B
<2><70>: Abbrev Number: 6 (DW_TAG_template_type_param)
<71> DW_AT_type : <0x7d>
...
Befor this patch, GDB would not create any symbols for the read template
tag DIEs and thus lose knowledge about them. Breaking at the return
statement and printing f's type would read
(gdb) ptype f
type = class Foo<double, int, float> [with B = int] {
<no data fields>
}
After this patch GDB does generate symbols from the DWARF (with their
artificial names:
(gdb) ptype f
type = class Foo<double, int, float> [with <unnamed0> = double, B = int,
<unnamed1> = float] {
<no data fields>
}
The same principle theoretically applies to template functions. Also
here, GDB would not record unnamed template TAGs but I know of no visual
way to trigger and test this changed behavior. Template functions do
not emit a '[with...]' list and their name generation also does not
suffer from template tags without names. GDB does not check whether or
not a template tag has a name in 'dwarf2_compute_name' and thus, the
names of the template functions are created independently of whether or
not the template TAGs have a DW_TAT_name attribute. A testcase has
been added in the gdb.dwarf2 for template classes and structs.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28396
|
|
When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.
However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.
The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name. This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.
An example might make this more clear. Given the following code
>> cat c.cpp
int foo (int a, float b)
{
return 0;
}
int main (int argc, char **argv)
{
return 0;
}
which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:
>> clang --version
clang version 10.0.0-4ubuntu1
...
>> clang -O0 -g ./c.cpp
>> gdb -q ./a.out -ex "start"
...
(gdb) disassemble main
Dump of assembler code for function main(int, char**):
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function _Z3fooif:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:
>> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
<3d> DW_AT_name : (indirect string, offset: 0x42): foo
<41> DW_AT_decl_file : 1
<42> DW_AT_decl_line : 1
<43> DW_AT_type : <0x9a>
Now, let's rename the C++ file and compile it as C:
>> mv c.cpp c.c
>> clang -O0 -g ./c.c
>> gdb -q ./a.out -ex "start'
...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:
>> objdump --dwarf=info ./a.out | grep foo -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name : (indirect string, offset: 0x37): foo
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 1
<3f> DW_AT_prototyped : 1
To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range. This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
|
|
GDB overwrites Python's sys.stdout and sys.stderr, but does not
properly implement the 'flush' method -- it only ever will flush
stdout. This patch fixes the bug. I couldn't find a straightforward
way to write a test for this.
|
|
When running the included test-case, we run into:
...
(gdb) break _start^M
read.h:309: internal-error: set_length: \
Assertion `m_length == length' failed.^M
...
The problem is that while there are two CUs:
...
$ readelf -wi debug-names-missing-cu | grep @
Compilation Unit @ offset 0x0:
Compilation Unit @ offset 0x2d:
...
the CU table in the .debug_names section only contains the first one:
...
CU table:
[ 0] 0x0
...
The incomplete CU table makes create_cus_from_debug_names_list set the size of
the CU at 0x0 to the actual size of both CUs combined.
This eventually leads to the assert, when we read the actual size from the CU
header.
While having an incomplete CU table in a .debug_names section is incorrect,
we need a better failure mode than asserting.
The easiest way to fix this is to set the length to 0 (meaning: unkown) in
create_cus_from_debug_names_list.
This makes the failure mode to accept the incomplete CU table, but to ignore
the missing CU.
It would be nice to instead reject the .debug_names index, and build a
complete CU list, but the point where we find this out is well after
dwarf2_initialize_objfile, so it looks rather intrusive to restart at that
point.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29453
|
|
Compared to the previous version, this version fixes the comments reported by
Tom Tromey and ensures that the 'help some-user-documented-alias'
shows the alias definition to ensure the user understands this is an
alias even if specifically documented.
When using 'help ALIASNAME', GDB shows the help of the aliased command.
This is a good default behaviour.
However, GDB alias command allows to define aliases with arguments
possibly changing or tuning significantly the behaviour of
the aliased command. In such a case, showing the help of the aliased
command might not be ideal.
This is particularly true when defining an alias as a set of
nested 'with' followed by a last command to launch, such as:
(gdb) alias pp10 = with print pretty -- with print elements 10 -- print
Asking 'help pp10' shows the help of the 'with' command, which is
not particularly useful:
(gdb) help pp10
with, pp10, w
alias pp10 = with print pretty -- with print elements 10 -- print
Temporarily set SETTING to VALUE, run COMMAND, and restore SETTING.
Usage: with SETTING [VALUE] [-- COMMAND]
....
Such an alias can now be documented by the user:
(gdb) document pp10
>Pretty printing an expressiong, printing 10 elements.
>Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
>See 'help print' for more information.
>end
(gdb) help pp10
alias pp10 = with print pretty -- with print elements 10 -- print
Pretty printing an expressiong, printing 10 elements.
Usage: pp10 [PRINT-COMMAND-OPTIONS] EXP
See 'help print' for more information.
(gdb)
When a user-defined alias is documented specifically, help and apropos
use the provided alias documentation instead of the documentation of
the aliased command.
Such a documented alias is also not shown anymore in the help of the
aliased command, and the alias is not listed anymore in the help
of the aliased command. In particular for cases such as pp10 example above,
indicating that pp10 is an alias of the 'with' command is confusing.
|
|
When debugging a certain class of GDB bug, I often end up wanting to
know what GDB thinks the frame-id is in a particular frame. It's
not too hard to pull this from some debug output, but I thought it
might be nice if there was a maintenance command that could tell us.
This commit adds 'maint print frame-id' which prints the frame-id of
the currently selected frame. You can also pass a frame level number
to find the frame-id for a specific frame.
There's a new test too.
|
|
I noticed that gdbpy_parse_register_id would assert if passed a Python
object of a type it was not expecting. The included test case shows
this crash. This patch fixes the problem and also changes
gdbpy_parse_register_id to be more "Python-like" -- it always ensures
the Python error is set when it fails, and the callers now simply
propagate the existing exception.
|
|
As Luis pointed out here [1], the AArch64 variant of the test doesn't
work on systems that use PIE by default. For example, on this Debian
11:
$ make check TESTS="gdb.dwarf2/entry-value-typedef.exp"
gdb compile failed, /usr/bin/ld: /tmp/ccJE8ZSr.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `_ZNSsD1Ev@@GLIBCXX_3.4' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /tmp/ccJE8ZSr.o(.text+0x38): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `_ZNSsD1Ev@@GLIBCXX_3.4'
This is because entry-value-typedef-aarch64.S was generated on an old
system that does not generate position-independent code by default, but
the system the test runs on tries to link the test executable as
position-independent. Fix this by regenerating the same binary on the
same system as the original one, but with -fPIE this time. Do the same
for the amd64 binary, although this one was already position-independent
so the generated code doesn't change.
With this patch applied, the test passes on the Debian 11 AArch64
system.
[1] https://sourceware.org/pipermail/gdb-patches/2022-August/191462.html
Change-Id: I68d55adaa56a7a3eddb0c13980b1a98b791f8144
|
|
Clang 15.0.0 enabled the warning for deprecated non-prototype functions
by default: https://reviews.llvm.org/D122895
Callfuncs.exp is impacted and won't run due to new warnings:
callfuncs.c:339:5: warning: a function declaration without a prototype is
deprecated in all versions of C and is not supported in C2x
[-Wdeprecated-non-prototype]
int t_float_values (float_arg1, float_arg2)
This patch disables those warnings with -Wno-deprecated-non-prototype.
Removing the test for deprecated syntax would also be an option. But I will
leave that up for others to decide/implement.
|
|
To cite gdb.exp:
Some C/C++ testcases unconditionally pass -Wno-foo as additional
options to disable some warning. That is OK with GCC, because
by design, GCC accepts any -Wno-foo option, even if it doesn't
support -Wfoo. Clang however warns about unknown -Wno-foo by
default, unless you pass -Wno-unknown-warning-option as well.
We do that here, so that individual testcases don't have to
worry about it.
This patch adds the same option that already exists for clang for icx and
adds the equivalent icc option.
|
|
Bug 29374 shows this crash:
$ ./gdb -nx --data-directory=data-directory -q -batch -ex "catch throw" -ex r -ex bt a.out
...
/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217: internal-error: copy: Assertion `dest.size () == src.size ()' failed.
The backtrace is:
#0 internal_error (file=0x5555606504c0 "/home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h", line=217, fmt=0x55556064b700 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:51
#1 0x000055555d41c0bb in gdb::copy<unsigned char const, unsigned char> (src=..., dest=...) at /home/simark/src/binutils-gdb/gdb/../gdbsupport/array-view.h:217
#2 0x000055555deef28c in dwarf_expr_context::fetch_result (this=0x7fffffffb830, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1040
#3 0x000055555def0015 in dwarf_expr_context::evaluate (this=0x7fffffffb830, addr=0x62f00004313e "0", len=1, as_lval=false, per_cu=0x60b000069550, frame=0x621007c9e910, addr_info=0x0, type=0x621007a86830, subobj_type=0x621007a86830, subobj_offset=0) at /home/simark/src/binutils-gdb/gdb/dwarf2/expr.c:1091
#4 0x000055555e084327 in dwarf2_evaluate_loc_desc_full (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, subobj_type=0x621007a86830, subobj_byte_offset=0, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1485
#5 0x000055555e0849e2 in dwarf2_evaluate_loc_desc (type=0x621007a86830, frame=0x621007c9e910, data=0x62f00004313e "0", size=1, per_cu=0x60b000069550, per_objfile=0x613000006080, as_lval=false) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1529
#6 0x000055555e0828c6 in dwarf_entry_parameter_to_value (parameter=0x621007a96e58, deref_size=0x0, type=0x621007a86830, caller_frame=0x621007c9e910, per_cu=0x60b000069550, per_objfile=0x613000006080) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1235
#7 0x000055555e082f55 in value_of_dwarf_reg_entry (type=0x621007a86890, frame=0x621007acc510, kind=CALL_SITE_PARAMETER_DWARF_REG, kind_u=...) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1332
#8 0x000055555e083449 in value_of_dwarf_block_entry (type=0x621007a86890, frame=0x621007acc510, block=0x61e000033568 "T\004\205\001\240\004\004\243\001T\237\004\240\004\261\004\001T\004\261\004\304\005\004\243\001T\237\004\304\005\310\005\001T\004\310\005\311\005\004\243\001T\237", block_len=1) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:1365
#9 0x000055555e094d40 in loclist_read_variable_at_entry (symbol=0x621007a99bd0, frame=0x621007acc510) at /home/simark/src/binutils-gdb/gdb/dwarf2/loc.c:3889
#10 0x000055555f5192e0 in read_frame_arg (fp_opts=..., sym=0x621007a99bd0, frame=0x621007acc510, argp=0x7fffffffbf20, entryargp=0x7fffffffbf60) at /home/simark/src/binutils-gdb/gdb/stack.c:559
#11 0x000055555f51c352 in print_frame_args (fp_opts=..., func=0x621007a99ad0, frame=0x621007acc510, num=-1, stream=0x6030000bad90) at /home/simark/src/binutils-gdb/gdb/stack.c:887
#12 0x000055555f521919 in print_frame (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, sal=...) at /home/simark/src/binutils-gdb/gdb/stack.c:1390
#13 0x000055555f51f22e in print_frame_info (fp_opts=..., frame=0x621007acc510, print_level=1, print_what=LOCATION, print_args=1, set_current_sal=0) at /home/simark/src/binutils-gdb/gdb/stack.c:1116
#14 0x000055555f526c6d in backtrace_command_1 (fp_opts=..., bt_opts=..., count_exp=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2079
#15 0x000055555f527ae5 in backtrace_command (arg=0x0, from_tty=0) at /home/simark/src/binutils-gdb/gdb/stack.c:2198
The problem is that the type that gets passed down to
dwarf_expr_context::fetch_result (the type of a variable of which we're
trying to read the entry value) is a typedef whose size has never been
computed yet (check_typedef has never been called on it). As we get in
the DWARF_VALUE_STACK case (line 1028 of dwarf2/expr.c), the `len`
variable is therefore set to 0, instead of the actual type length. We
then call allocate_value on subobj_type, which does call check_typedef,
so the length of the typedef gets filled in at that point. We end up
passing to the copy function a source array view of length 0 and a
target array view of length 4, and the assertion fails.
Fix this by calling check_typedef on both type and subobj_type at the
beginning of fetch_result.
I tried writing a test for this using the DWARF assembler, but I haven't
succeeded. It's possible that we need to get into this specific code
path (value_of_dwarf_reg_entry and all) to manage to get to
dwarf_expr_context::fetch_result with a typedef type that has never been
resolved. In all my attempts, the typedef would always be resolved
already, so the bug wouldn't show up.
As a fallback, I made a gdb.dwarf2 test with compiler-generated .S
files. I don't particularly like those, but I think it's better than no
test. The .cpp source code is the smallest reproducer I am able to make
from the reproducer given in the bug (thanks to Pedro for suggestions on
how to minimize it further than I had). Since I tested on both amd64
and aarch64, I added versions of the test for these two architectures.
Change-Id: I182733ad08e34df40d8bcc47af72c482fabf4900
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29374
|
|
It exercises a bug that GDB previously had where it would lose track of
some registers when the inferior changed its vector length.
It also checks that the vg register and the size of the z0-z31 registers
correctly reflect the new vector length.
|
|
Correctly report PARAM_ZUINTEGER_UNLIMITED rather than PARAM_ZUINTEGER
in testing a Python parameter of the PARAM_ZUINTEGER_UNLIMITED type.
|
|
I noticed that the gdb.arch/riscv-unwind-long-insn.exp test was
failing when run on a 64-bit RISC-V target.
The problem was that GDB was failing to stop after a finish command,
and was then running to an unexpected location.
The reason GDB failed to stop at the finish breakpoint was that the
frame-id of the inferior, when we reached the finish breakpoint,
didn't match the expected frame-id that was stored on the breakpoint.
The reason for this mismatch was that the assembler code that is
included in this test, was written only taking 32-bit RISC-V into
account, as a result, the $fp register was being corrupted, and this
was causing the frame-id mismatch.
Specifically, the $fp register would end up being sign-extended from
32 to 64 bits. If the expected $fp value has some significant bits
above bit 31 then the computed and expected frame-ids would not match.
To fix this I propose merging the two .s files into a single .S file,
and making use of preprocessor macros to specialise the file for the
correct size of $fp. There are plenty of existing tests that already
make use of preprocessor macros in assembler files, so I assume this
approach is fine.
Once I'd decided to make use of preprocessor macros to solve the 32/64
bit issue, then I figured I might as well merge the two test assembler
files, they only differed by a single instruction.
With this change in place I now see this test fully passing on 32 and
64 bit RISC-V targets.
|
|
Commit 9db0d8536dbc ("gdb/mi: fix breakpoint script field output") fixed
the output of the script key in the MI breakpoint output, from
script={"print 10","continue"}
to
script=["print 10","continue"]
However, it missed updating this test case, which still tests for the
old (broken) form, causing:
FAIL: gdb.mi/mi-break.exp: mi-mode=main: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
FAIL: gdb.mi/mi-break.exp: mi-mode=separate: test_breakpoint_commands: breakpoint commands: check that commands are set (unexpected output)
Update the test to expect the new form.
Change-Id: I174919d4eea53e96d914ca9bd1cf6f01c8de30b8
|
|
When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
have:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
(gdb) continue^M
Continuing.^M
^M
Breakpoint 2, 0x00000000004004c4 in \
compdir_missing__ldir_missing__file_basename () \
at tmp-dw2-dir-file-name.c:999^M
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
compdir_missing__ldir_missing__file_basename
...
When trying to set a breakpoint on
compdir_missing__ldir_missing__file_basename, the architecture-specific
prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
...
00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
4004c0: 55 push %rbp
4004c1: 48 89 e5 mov %rsp,%rbp
4004c4: 8b 05 72 1b 20 00 mov 0x201b72(%rip),%eax # 60203c <v>
4004ca: 83 c0 01 add $0x1,%eax
4004cd: 89 05 69 1b 20 00 mov %eax,0x201b69(%rip) # 60203c <v>
4004d3: 90 nop
4004d4: 5d pop %rbp
4004d5: c3 ret
...
And because the line table info is rudamentary:
...
CU: tmp-dw2-dir-file-name.c:
File name Line number Starting address View Stmt
tmp-dw2-dir-file-name.c 999 0x4004c0 x
tmp-dw2-dir-file-name.c 1000 0x4004d6 x
tmp-dw2-dir-file-name.c - 0x4004d6
...
the address does not fall at an actual line, so the breakpoint is shown with
address, both when setting it and hitting it.
when running the test-case with aarch64-linux, we have similarly:
...
(gdb) break compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
...
due to the architecture-specific prologue skipper starting at 0x400610 and
skipping past two insns, to 0x400618:
...
0000000000400610 <compdir_missing__ldir_missing__file_basename>:
400610: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400614: 9100b000 add x0, x0, #0x2c
400618: b9400000 ldr w0, [x0]
40061c: 11000401 add w1, w0, #0x1
400620: 90000100 adrp x0, 420000 <__libc_start_main@GLIBC_2.17>
400624: 9100b000 add x0, x0, #0x2c
400628: b9000001 str w1, [x0]
40062c: d503201f nop
400630: d65f03c0 ret
...
But interestingly, the aarch64 architecture-specific prologue skipper is
wrong. There is no prologue, and the breakpoint should be set at 0x400610.
By using "break *compdir_missing__ldir_missing__file_basename"
we can get the breakpoint set at 0x400610:
...
(gdb) break *compdir_missing__ldir_missing__file_basename^M
Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
...
and make the test-case independent of prologue analysis.
This requires us to update the expected patterns.
The fix ensures that once the aarch64 architecture-specific prologue skipper
will be fixed, this test-case won't start failing.
Tested on x86_64-linux.
|
|
When doing varobj_re_set, we currently try to recreate floating varobj.
This was introduced by 4e969b4f0128 "Re-evaluate floating varobj as part
of varobj_invalidate" to deal with use a after free issue. However
since bc20e562ec0 "Fix use after free in varobj" we now ensure that we
never have dangling pointers so this all recreation is not strictly
needed anymore for floating varobjs.
This commit proposes to remove this recreation process for floating
varobjs.
Tested on x86_64-linux.
|
|
[This patch is a followup to the discussion in
https://sourceware.org/pipermail/gdb-patches/2022-August/191188.html]
PR/29426 shows failures when running the gdb.mi/mi-var-invalidate-shlib
test when using a compiler which does not produce a PIE executable by
default.
In the testcase, a varobj is created to track a global variable, and
then the main binary is reloaded in GDB (using the file command).
During the load of the new binary, GDB tries to recreate the varobj to
track the global in the new binary (varobj_invalidate_iter). At this
point, the old process is still in flight. So when we try to access to
the value of the global, in a PIE executable we only have access to the
unrelocated address (the objfile's text_section_offset () is 0). As a
consequence down the line read_value_memory fails to read the unrelated
address, so cannot evaluate the value of the global. Note that the
expression used to access to the global’s value is valid, so the varobj
can be created. When using a non PIE executable, the address of the
global GDB knows about at this point does not need relocation, so
read_value_memory can access the (old binary’s) value.
So at this point, in the case of a non-PIE executable the value field is
set, while it is cleared in the case of PIE executable. Later when the
test issues a "-var-update global_var", the command sees no change in
the case of the non-PIE executable, while in the case of the PIE
executable install_new_value sees that value changes, leading to a
different output.
This patch makes sure that, as we do for breakpoints, we wait until
relocation has happened before we try to recreate varobjs. This way we
have a consistent behavior between PIE and non-PIE binaries.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29426
Co-authored-by: Lancelot SIX <lancelot.six@amd.com>
|
|
The varobj_invalidate_iter function has logic to invalidate any local
varobj it can find. However since bc20e562ec0 "gdb/varobj: Fix use
after free in varobj" all varobj containing references to an objfile are
cleared when the objfile goes out of scope. This means that at this
point any local varobj seen by varobj_invalidate_iter either has
already been invalidated by varobj_invalidate_if_uses_objfile or only
contains valid references and there is no reason to invalidate it.
This patch proposes to remove this unnecessary invalidation and adds a
testcase which exercises a scenario where a local varobj can legitimately
survive a call to varobj_invalidate_iter.
At this point the varobj_invalidate and varobj_invalidate_iter seem
misnamed since they deal with re-creating invalid objects and do not do
invalidation, but this will be fixed in a following patch.
Tested on x86_64-linux.
|
|
The "script" field, output whenever information about a breakpoint with
commands is output, uses wrong MI syntax.
$ ./gdb -nx -q --data-directory=data-directory -x script -i mi
=thread-group-added,id="i1"
=breakpoint-created,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",original-location="main"}
=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}
(gdb)
-break-info
^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x000000000000111d",func="main",file="test.c",fullname="/home/simark/build/binutils-gdb-one-target/gdb/test.c",line="3",thread-groups=["i1"],times="0",script={"aaa","bbb","ccc"},original-location="main"}]}
(gdb)
In both the =breakpoint-modified and -break-info output, we have:
script={"aaa","bbb","ccc"}
According to the output syntax [1], curly braces means tuple, and a
tuple contains key=value pairs. This looks like it should be a list,
but uses curly braces by mistake. This would make more sense:
script=["aaa","bbb","ccc"]
Fix it, keeping the backwards compatibility by introducing a new MI
version (MI4), in exactly the same way as was done when fixing
multi-locations breakpoint output in [2].
- Add a fix_breakpoint_script_output uiout flag. MI uiouts will use
this flag if the version is >= 4.
- Add a fix_breakpoint_script_output_globally variable and the
-fix-breakpoint-script-output MI command to set it, if frontends want
to use the fixed output for this without using the newer MI version.
- When emitting the script field, use list instead of tuple, if we want
the fixed output (depending on the two criteria above)
-
[1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Output-Syntax.html#GDB_002fMI-Output-Syntax
[2] https://gitlab.com/gnutools/binutils-gdb/-/commit/b4be1b0648608a2578bbed39841c8ee411773edd
Change-Id: I7113c6892832c8d6805badb06ce42496677e2242
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24285
|
|
When running on a native RISC-V Linux target I currently see failures
in the gdb.arch/riscv-reg-aliases.exp test like this:
set $ft0.float = 501
(gdb) PASS: gdb.arch/riscv-reg-aliases.exp: write non-zero value to ft0
p/d $ft0.float
$263 = 1140490240
(gdb) FAIL: gdb.arch/riscv-reg-aliases.exp: read ft0 after non-zero write to ft0
This test started failing after this commit:
commit 56262a931b7ca8ee3ec9104bc7e9e0b40cf3d64e
Date: Thu Feb 17 13:43:59 2022 -0700
Change how "print/x" displays floating-point value
The problem is that when 501 is written to $ft0.float the value is
converted to floating point format and stored in the register. Prior
to the above commit printing with /x and /d would first extract the
value as a float, and then convert the value to an integer for
display. After the above commit GDB now uses the raw register value
when displaying /x and /d, and so we see this behaviour:
(gdb) info registers $ft0
ft0 {float = 501, double = 5.6347704700123827e-315} (raw 0x0000000043fa8000)
(gdb) p/f $ft0.float
$1 = 501
(gdb) p/d $ft0.float
$2 = 1140490240
(gdb) p/x $ft0.float
$3 = 0x43fa8000
To fix this test I now print the float registers using the /f format
rather than /d. With this change the test now passes.
|
|
When running test-case gdb.dwarf2/debug-names.exp on openSUSE Tumbleweed, I
run into:
...
(gdb) maint info symtabs^M
...
ERROR: internal buffer is full.
UNRESOLVED: gdb.dwarf2/debug-names.exp: break _start expanded symtab
...
Fix this by simplifying the test-case to print _start rather running to it.
Tested on x86_64-linux.
|
|
When loading the debug-names-duplicate-cu executable included in this
test-case, we run into:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
src/gdb/dwarf2/read.c:2353: internal-error: read_addrmap_from_aranges: \
Assertion `insertpair.second' failed.^M
...
This assert was added in recent commit 75337cbc147 ("[gdb/symtab] Fix
.debug_aranges duplicate offset warning").
The assert triggers because the CU table in the .debug_names section contains
a duplicate:
...
Version 5
Augmentation string: 47 44 42 00 ("GDB")
CU table:
[ 0] 0x0
[ 1] 0x0
...
Fix this by rejecting the .debug_names index:
...
(gdb) file debug-names-duplicate-cu^M
Reading symbols from debug-names-duplicate-cu...^M
warning: Section .debug_names has duplicate entry in CU table, \
ignoring .debug_names.^M
...
Likewise for the case where the CU table is not sorted by increasing offset.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29436
|
|
Add:
- support for a per-module .debug_names section in the dwarf assembler, and
- a test-case excercising this new functionality.
A per-module .debug_names section needs to have an entry in the CU list for
each CU in the module, which is made more difficult by two things:
- linking in other objects, which may contain additional CUs
(typically the case on openSUSE), and
- adding dummy CUs in the dwarf assembler.
We handle this by:
- compiling with -nostartfiles (so the test-case contains _start rather than
main), and
- disabling the dummy CU generation for the test-case.
I've kept things simple by having the test-case specify the hash value, rather
than adding that functionality in the dwarf assembler.
Also I've kept the bucket count to 1, which makes it trivial to satisfy the
requirement that "the symbol is entered into a bucket whose index is the hash
value modulo bucket_count".
The readelf dump of the .debug_names section from the test-case looks like:
...
Version 5
Augmentation string: 47 44 42 00 ("GDB")
CU table:
[ 0] 0x0
TU table:
Foreign TU table:
Used 1 of 1 bucket.
Out of 2 items there are 1 bucket clashes (longest of 1 entries).
Symbol table:
[ 0] #eddb6232 _start: <1> DW_TAG_subprogram DW_IDX_compile_unit=0
[ 1] #0b888030 int: <2> DW_TAG_base_type DW_IDX_compile_unit=0
...
Tested on x86_64-linux.
|
|
When running test-case gdb.dwarf2/fission-loclists.exp, I noticed:
...
warning: Section .debug_aranges in fission-loclists has duplicate \
debug_info_offset 0x8f, ignoring .debug_aranges.^M
...
Fix this by removing the duplicate .debug_aranges entry.
Tested on x86_64-linux.
|
|
In PR23888 an error is reported:
...
ERROR: tcl error sourcing watchpoint-unaligned.exp.
ERROR: expected boolean value but got ""
while executing
"if {$wpnum} {
...
This presumably happens when:
- skip_hw_watchpoint_tests returns 0 meaning hw watchpoints are supported
- gdb fails to set a hw watchpoint and instead sets a sw watchpoint
That particular situation is handled for arm:
...
-re "Watchpoint (\[0-9\]+): .*\r\n$gdb_prompt $" {
if {[istarget "arm*-*-*"]} {
untested $test
set wpnum 0
}
}
...
but not for any other targets so wpnum remains "", triggering the ERROR.
Possibly this has been fixed for powerpc by commit 8d4e4d13afb ("gdb Power 9
add test for HW watchpoint support."), but it's still possible for other
targets.
Fix this by:
- initializing wpnum to 0 instead of ""
- signalling the failure to set a hw watchpoint by a fail
Tested on x86_64-linux, also by adding:
...
gdb_test_no_output "set can-use-hw-watchpoints 0"
...
and verifying that it triggers the fail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23888
|
|
The function read_addrmap_from_aranges contains code to issue a warning:
...
if (!insertpair.second)
{
warning (_("Section .debug_aranges in %s has duplicate "
"debug_info_offset %s, ignoring .debug_aranges."),
objfile_name (objfile), sect_offset_str (per_cu->sect_off));
return false;
}
...
but the warning is in fact activated when all_comp_units has duplicate
entries, which is very misleading.
Fix this by:
- adding a test-case that should trigger the warning,
- replacing the current implementation of the warning with an
assert that all_comp_units should not contain duplicates, and
- properly re-implementing the warning, such that it is triggered
by the test-case.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29381
|
|
On aarch64-linux, I run into:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = 18446744073709551615^M
(gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...
while on x86_64-linux instead, I get:
...
(gdb) print 16#ffffffffffffffff#^M
$7 = -1^M
(gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff#
...
We can easily reproduce this on x86_64-linux using:
...
$ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \
-ex "print 16#ffffffffffffffff#"
$1 = -1
$ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \
-ex "print 16#ffffffffffffffff#"
$1 = 18446744073709551615
...
With i386, we have:
...
(gdb) p int_bits
$3 = 32
(gdb) p long_bits
$4 = 32
(gdb) p long_long_bits
$5 = 64
...
and so in processInt we hit the fits-in-unsigned-long-long case where we use
as type long long:
...
/* Note: Interprets ULLONG_MAX as -1. */
yylval.typed_val.type = type_long_long (par_state);
...
With aarch64, we have instead:
...
(gdb) p int_bits
$1 = 32
(gdb) p long_bits
$2 = 64
(gdb) p long_long_bits
$3 = 64
...
and so in processInt we hit the fits-in-unsigned-long case where we use
as type unsigned long:
...
yylval.typed_val.type
= builtin_type (par_state->gdbarch ())->builtin_unsigned_long;
...
It's not clear why for ada we're using long long for the
fits-in-unsigned-long-long case.
Fix this by using unsigned long long for the fits-in-unsigned-long-long case,
meaning the new reference output is 18446744073709551615 instead of -1.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416
|
|
Using different ways of passing source file paths to compilers results n
different file and directory paths in the line header. For example:
- gcc foo.c
- gcc ./foo.c
- gcc ../cwd/foo.c
- gcc $PWD/foo.c
Because of this, GDB sometimes failed to look up macros. The previous
patch fixed that as much as possible. This patch adds the corresponding
tests.
Add both a DWARF assembler-based test and a regular test. The DWARF
assembled-based one tests some hard-coded debug info based on what I
have observed some specific versions of gcc and clang generate. We want
to make sure that GDB keeps handling all these cases correctly, even if
it's not always clear whether they are really valid DWARF. Also, they
will be tested no matter what the current target compiler is for a given
test run.
The regular test is compiled using the target compiler, so it may help
find bugs when testing against some other toolchains than what was used
to generate the DWARF assembler-based test.
For the DWARF assembler-based test, add to testsuite/lib/dwarf.exp the
necessary code to generate a DWARF5 .debug_macro section. The design of
the new procs is based on what was done for rnglists and loclists.
To test against a specific compiler one can use this command, for
example:
$ make check TESTS="gdb.base/macro-source-path.exp" RUNTESTFLAGS="CC_FOR_TARGET=clang --target_board unix/gdb:debug_flags=-gdwarf-5"
Change-Id: Iab8da498e57d10cc2a3d09ea136685d9278cfcf6
|
|
On aarch64-linux I run into this failure with gcc 7.5.0:
...
(gdb) print $item.started^M
$1 = (-5312, 65535, 4202476)^M
(gdb) FAIL: gdb.ada/convvar_comp.exp: print $item.started
...
The test-case expects (0, 0, 0), but we're getting another value due to
incorrect location information.
Work around this by:
- first printing the value, and then
- verifying that the convenience variable matches the printed value.
I've verified that the test-case still checks what it should by disabling
the fix from commit cc0e770c0d0 ("memory error printing component of record
from convenience variable") and observing the test-case fail.
Tested on x86_64-linux and aarch64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29420
|
|
On aarch64 (and likewise on arm), I run into:
...
(gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior
Executing on target: kill -9 11516 (timeout = 300)
builtin_spawn -ignore SIGHUP kill -9 11516^M
continue^M
Continuing.^M
Unable to fetch general registers: No such process.^M
(gdb) [Thread 0xfffff7d511e0 (LWP 11518) exited]^M
^M
Program terminated with signal SIGKILL, Killed.^M
The program no longer exists.^M
FAIL: gdb.threads/killed-outside.exp: prompt after first continue (timeout)
...
due to a mismatch between the actual "No such process" line and the expected
one:
...
set no_such_process_msg "Couldn't get registers: No such process\."
...
Fix this by updating the regexp.
Tested on aarch64-linux, and x86_64-linux.
|
|
PR python/18385
v7:
This version addresses the issues pointed out by Tom.
Added nullchecks for Python object creations.
Changed from using PyLong_FromLong to the gdb_py-versions.
Re-factored some code to make it look more cohesive.
Also added the more safe Python reference count decrement PY_XDECREF,
even though the BreakpointLocation type is never instantiated by the
user (explicitly documented in the docs) decrementing < 0 is made
impossible with the safe call.
Tom pointed out that using the policy class explicitly to decrement a
reference counted object was not the way to go, so this has instead been
wrapped in a ref_ptr that handles that for us in blocpy_dealloc.
Moved macro from py-internal to py-breakpoint.c.
Renamed section at the bottom of commit message "Patch Description".
v6:
This version addresses the points Pedro gave in review to this patch.
Added the attributes `function`, `fullname` and `thread_groups`
as per request by Pedro with the argument that it more resembles the
output of the MI-command "-break-list". Added documentation for these attributes.
Cleaned up left overs from copy+paste in test suite, removed hard coding
of line numbers where possible.
Refactored some code to use more c++-y style range for loops
wrt to breakpoint locations.
Changed terminology, naming was very inconsistent. Used a variety of "parent",
"owner". Now "owner" is the only term used, and the field in the
gdb_breakpoint_location_object now also called "owner".
v5:
Changes in response to review by Tom Tromey:
- Replaced manual INCREF/DECREF calls with
gdbpy_ref ptrs in places where possible.
- Fixed non-gdb style conforming formatting
- Get parent of bploc increases ref count of parent.
- moved bploc Python definition to py-breakpoint.c
The INCREF of self in bppy_get_locations is due
to the individual locations holding a reference to
it's owner. This is decremented at de-alloc time.
The reason why this needs to be here is, if the user writes
for instance;
py loc = gdb.breakpoints()[X].locations[Y]
The breakpoint owner object is immediately going
out of scope (GC'd/dealloced), and the location
object requires it to be alive for as long as it is alive.
Thanks for your review, Tom!
v4:
Fixed remaining doc issues as per request
by Eli.
v3:
Rewritten commit message, shortened + reworded,
added tests.
Patch Description
Currently, the Python API lacks the ability to
query breakpoints for their installed locations,
and subsequently, can't query any information about them, or
enable/disable individual locations.
This patch solves this by adding Python type gdb.BreakpointLocation.
The type is never instantiated by the user of the Python API directly,
but is produced by the gdb.Breakpoint.locations attribute returning
a list of gdb.BreakpointLocation.
gdb.Breakpoint.locations:
The attribute for retrieving the currently installed breakpoint
locations for gdb.Breakpoint. Matches behavior of
the "info breakpoints" command in that it only
returns the last known or currently inserted breakpoint locations.
BreakpointLocation contains 7 attributes
6 read-only attributes:
owner: location owner's Python companion object
source: file path and line number tuple: (string, long) / None
address: installed address of the location
function: function name where location was set
fullname: fullname where location was set
thread_groups: thread groups (inferiors) where location was set.
1 writeable attribute:
enabled: get/set enable/disable this location (bool)
Access/calls to these, can all throw Python exceptions (documented in
the online documentation), and that's due to the nature
of how breakpoint locations can be invalidated
"behind the scenes", either by them being removed
from the original breakpoint or changed,
like for instance when a new symbol file is loaded, at
which point all breakpoint locations are re-created by GDB.
Therefore this patch has chosen to be non-intrusive:
it's up to the Python user to re-request the locations if
they become invalid.
Also there's event handlers that handle new object files etc, if a Python
user is storing breakpoint locations in some larger state they've
built up, refreshing the locations is easy and it only comes
with runtime overhead when the Python user wants to use them.
gdb.BreakpointLocation Python type
struct "gdbpy_breakpoint_location_object" is found in python-internal.h
Its definition, layout, methods and functions
are found in the same file as gdb.Breakpoint (py-breakpoint.c)
1 change was also made to breakpoint.h/c to make it possible
to enable and disable a bp_location* specifically,
without having its LOC_NUM, as this number
also can change arbitrarily behind the scenes.
Updated docs & news file as per request.
Testsuite: tests the .source attribute and the disabling of
individual locations.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18385
Change-Id: I302c1c50a557ad59d5d18c88ca19014731d736b0
|
|
When running test-case gdb.opt/inline-small-func.exp with clang 12.0.1, I run
into:
...
gdb compile failed, /usr/bin/ld: inline-small-func0.o: in function `main':
inline-small-func.c:21: undefined reference to `callee'
clang-12.0: error: linker command failed with exit code 1 \
(use -v to see invocation)
UNTESTED: gdb.opt/inline-small-func.exp: failed to prepare
...
Fix this by using __attribute__((always_inline)).
Tested on x86_64-linux.
|
|
The varobj_invalidate function is meant to be called when restarting a
process, and check at this point if some of the previously existing
varobj can be recreated in the context of the new process.
Two kind of varobj are subject to re-creation: global varobj (i.e.
varobj which reference a global variable), and floating varobj (i.e.
varobj which are always re-evaluated in the context of whatever is
the currently selected frame at the time of evaluation).
However, in the re-creation process, the varobj_invalidate_iter
recreates floating varobj as non-floating, due to an invalid parameter.
This patches fixes this and adds an assertion to check that if a varobj
is indeed recreated, it matches the original varobj "floating" property.
Another issue is that if at this recreation time the expression watched
by the floating varobj is not in scope, then the varobj is marked as
invalid. If later the user selects a frame where the expression becomes
valid, the varobj remains invalid and this is wrong. This patch also
make sure that floating varobj are not invalidated if they cannot be
evaluated.
The last important thing to note is that due to the previous patch, when
varobj_invalidate is executed (in the context of a new process), any
global var have already been invalidated (this has been done when the
objfile it referred to got invalidated). As a consequence,
varobj_invalidate tries to recreate vars which are already marked as
invalid. This does not entirely feels right, but I keep this behavior
for backward compatibility.
Tested on x86_64-linux
|
|
Varobj object contains references to types, variables (i.e. struct
variable) and expression. All of those can reference data on an
objfile's obstack. It is possible for this objfile to be deleted (and
the obstack to be feed), while the varobj remains valid. Later, if the
user uses the varobj, this will result in a use-after-free error. With
address sanitizer build, this leads to a plain error. For non address
sanitizer build we might see undefined behaviour, which manifest
themself as assertion failures when accessing data backed by feed
memory.
This can be observed if we create a varobj that refers to ta symbol in a
shared library, after either the objfile gets reloaded (using the `file`
command) or after the shared library is unloaded (with a call to dlclose
for example).
This patch fixes those issues by:
- Adding cleanup procedure to the free_objfile observable. When
activated this observer clears expressions referencing the objfile
being freed, and removes references to blocks belonging to this
objfile.
- Adding varobj support in the `preserve_values` (gdb.value.c). This
ensures that before the objfile is unloaded, any type owned by the
objfile referenced by the varobj is replaced by an equivalent type
not owned by the objfile. This process is done here instead of in the
free_objfile observer in order to reuse the type hash table already
used for similar purpose when replacing types of values kept in the
value history.
This patch also makes sure to keep a reference to the expression's
gdbarch and language_defn members when the varobj->root->exp is
initialized. Those structures outlive the objfile, so this is safe.
This is done because those references might be used initialize a python
context even after exp is invalidated. Another approach could have been
to initialize the python context with default gdbarch and language_defn
(i.e. nullptr) if expr is NULL, but since we might still try to display
the value which was obtained by evaluating exp when it was still valid,
keeping track of the context which was used at this time seems
reasonable.
Tested on x86_64-Linux.
Co-Authored-By: Pedro Alves <pedro@palves.net>
|
|
With the CLI testsuite's runto proc, we can pass "allow-pending" as an
option, like:
runto func allow-pending
That is currently not possible with MI's mi_runto, however. This
patch makes it possible, by adding a new "-pending" option to
mi_runto.
A pending breakpoint shows different MI attributes compared to a
breakpoint with a location, so the regexp returned by
mi_make_breakpoint isn't suitable. Thus, add a new
mi_make_breakpoint_pending proc for pending breakpoints.
Tweak mi_runto to let it take and pass down arguments.
Change-Id: I185fef00ab545a1df2ce12b4dbc3da908783a37c
|
|
After this commit:
commit 81384924cdcc9eb2676dd9084b76845d7d0e0759
Date: Tue Apr 5 11:06:16 2022 +0100
gdb: have gdb_disassemble_info carry 'this' in its stream pointer
The disassemble_info::stream field will no longer be a ui_file*. That
commit failed to update one location in py-disasm.c though.
While running some tests using the Python disassembler API, I
triggered a call to gdbpy_disassembler::print_address_func, and, as I
had compiled GDB with the undefined behaviour sanitizer, GDB crashed
as the code currently (incorrectly) casts the stream field to be a
ui_file*.
In this commit I fix this error.
In order to test this case I had to tweak the existing test case a
little. I also spotted some debug printf statements in py-disasm.py,
which I have removed.
|
|
This patch adds a test case to try to clear an internal python
breakpoint using the clear command.
This was suggested by Pedro during a code review of the following
commit.
commit a5c69b1e49bae4d0dcb20f324cebb310c63495c6
Date: Sun Apr 17 15:09:46 2022 +0800
gdb: fix using clear command to delete non-user breakpoints(PR cli/7161)
Tested on x86_64 openSUSE Tumbleweed.
|
|
The get_maint_bp_addr procedure will be shared by other test suite, so
move it to gdb-utils.exp.
Following Andrew's suggestion, I renamed get_maint_bp_addr to
gdb_get_bp_addr, since it would have handled normal breakpoints in
addition to the internal ones. Note that there is still room for
improvement in this procedure, which I indicated in comments nearby.
|
|
Some Ada tests repeat their test sequence with different gnat-encodings,
typically "all" and "minimal". However, they give the same name to both
binaries, meaning the second run overwrites the binary of the first run.
This makes it difficult and confusing when trying to reproduce problems
manually with the test artifacts. Change those tests to use unique
names for each pass.
Change-Id: Iaa3c9f041241249a7d67392e785c31aa189dcc88
|
|
In all-stop mode, when the target is itself in non-stop mode (like
GNU/Linux), if you use the "step N" (or "stepi/next/nexti N") to step
a thread a number of times:
(gdb) help step
step, s
Step program until it reaches a different source line.
Usage: step [N]
Argument N means step N times (or till program stops for another reason).
... GDB prematurely stops all threads after the first step, and
doesn't re-resume them for the subsequent N-1 steps. It's as if for
the 2nd and subsequent steps, the command was running with
scheduler-locking enabled.
This can be observed with the testcase added by this commit, which
looks like this:
static pthread_barrier_t barrier;
static void *
thread_func (void *arg)
{
pthread_barrier_wait (&barrier);
return NULL;
}
int
main ()
{
pthread_t thread;
int ret;
pthread_barrier_init (&barrier, NULL, 2);
/* We run to this line below, and then issue "next 3". That should
step over the 3 lines below and land on the return statement. If
GDB prematurely stops the thread_func thread after the first of
the 3 nexts (and never resumes it again), then the join won't
ever return. */
pthread_create (&thread, NULL, thread_func, NULL); /* set break here */
pthread_barrier_wait (&barrier);
pthread_join (thread, NULL);
return 0;
}
The test hangs and times out without the GDB fix:
(gdb) next 3
[New Thread 0x7ffff7d89700 (LWP 525772)]
FAIL: gdb.threads/step-N-all-progress.exp: non-stop=off: target-non-stop=on: next 3 (timeout)
The problem is a core gdb bug.
When you do "step/stepi/next/nexti N", GDB internally creates a
thread_fsm object and associates it with the stepping thread. For the
stepping commands, the FSM's class is step_command_fsm. That object
is what keeps track of how many steps are left to make. When one step
finishes, handle_inferior_event calls stop_waiting and returns, and
then fetch_inferior_event calls the "should_stop" method of the event
thread's FSM. The implementation of that method decrements the
steps-left counter. If the counter is 0, it returns true and we
proceed to presenting the stop to the user. If it isn't 0 yet, then
the method returns false, indicating to fetch_inferior_event to "keep
going".
Focusing now on when the first step finishes -- we're in "all-stop"
mode, with the target in non-stop mode. When a step finishes,
handle_inferior_event calls stop_waiting, which itself calls
stop_all_threads to stop everything. I.e., after the first step
completes, all threads are stopped, before handle_inferior_event
returns. And after that, now in fetch_inferior_event, we consult the
thread's thread_fsm::should_stop, which as we've seen, for the first
step returns false -- i.e., we need to keep_going for another step.
However, since the target is in non-stop mode, keep_going resumes
_only_ the current thread. All the other threads remain stopped,
inadvertently.
If the target is in non-stop mode, we don't actually need to stop all
threads right after each step finishes, and then re-resume them again.
We can instead defer stopping all threads until all the steps are
completed.
So fix this by delaying the stopping of all threads until after we
called the FSM's "should_stop" method. I.e., move it from
stop_waiting, to handle_inferior_events's callers,
fetch_inferior_event and wait_for_inferior.
New test included. Tested on x86-64 GNU/Linux native and gdbserver.
Change-Id: Iaad50dcfea4464c84bdbac853a89df92ade6ae01
|
