Added function fetch_tid_type which calls get_tid_type and will set up
the type, associated with a tid, if it is not read in yet. Also implement
function read_forward_type which handles the CTF_K_FORWARD kind.
Expanded gdb.base/ctf-ptype.exp to add cases with forward references.
gdb/ChangeLog:
* ctfread.c (fetch_tid_type): New function, use throughout file.
(read_forward_type): New function.
(read_type_record): Call read_forward_type.
gdb/testsuite/ChangeLog:
* gdb.base/ctf-ptype.c: Add struct link containing a forward
reference type.
* gdb.base/ctf-ptype.exp: Add "ptype struct link".
This commit replaces this patch:
https://sourceware.org/pipermail/gdb-patches/2021-January/174933.html
which was itself a replacement for this patch:
https://sourceware.org/pipermail/gdb-patches/2020-July/170335.html
The motivation behind the original patch can be seen in the new test,
which currently gives a GDB session like this:
(gdb) ptype var8
type = Type type6
PTR TO -> ( Type type2 :: ptr_1 )
PTR TO -> ( Type type2 :: ptr_2 )
End Type type6
(gdb) ptype var8%ptr_2
type = PTR TO -> ( Type type2
integer(kind=4) :: spacer
Type type1, allocatable :: t2_array(:) <------ Issue #1
End Type type2 )
(gdb) ptype var8%ptr_2%t2_array
Cannot access memory at address 0x38 <------ Issue #2
(gdb)
Issue #1: Here we see the abstract dynamic type, rather than the
resolved concrete type. Though in some cases the user might be
interested in the abstract dynamic type, I think that in most cases
showing the resolved concrete type will be of more use. Plus, the
user can always figure out the dynamic type (by source code inspection
if nothing else) given the concrete type, but it is much harder to
figure out the concrete type given only the dynamic type.
Issue #2: In this example, GDB evaluates the expression in
EVAL_AVOID_SIDE_EFFECTS mode (due to ptype). The value returned for
var8%ptr_2 will be a non-lazy, zero value of the correct dynamic
type. However, when GDB asks about the type of t2_array this requires
GDB to access the value of var8%ptr_2 in order to read the dynamic
properties. As this value was forced to zero (thanks to the use of
EVAL_AVOID_SIDE_EFFECTS) then GDB ends up accessing memory at a base
of zero plus some offset.
Both this patch, and my previous two attempts, have all tried to
resolve this problem by stopping EVAL_AVOID_SIDE_EFFECTS replacing the
result value with a zero value in some cases.
This new patch is influenced by how Ada handles its tagged typed.
There are plenty of examples in ada-lang.c, but one specific case is
ada_structop_operation::evaluate. When GDB spots that we are dealing
with a tagged (dynamic) type, and we're in EVAL_AVOID_SIDE_EFFECTS
mode, then GDB re-evaluates the child operation in EVAL_NORMAL mode.
This commit handles two cases like this specifically for Fortran, a
new fortran_structop_operation, and the already existing
fortran_undetermined, which is where we handle array accesses.
In these two locations we spot when we are dealing with a dynamic type
and re-evaluate the child operation in EVAL_NORMAL mode so that we
are able to access the dynamic properties of the type.
The rest of this commit message is my attempt to record why my
previous patches failed.
To understand my second patch, and why it failed lets consider two
expressions, this Fortran expression:
(gdb) ptype var8%ptr_2%t2_array --<A>
Operation: STRUCTOP_STRUCT --(1)
Operation: STRUCTOP_STRUCT --(2)
Operation: OP_VAR_VALUE --(3)
Symbol: var8
Block: 0x3980ac0
String: ptr_2
String: t2_array
And this C expression:
(gdb) ptype ptr && ptr->a == 3 --<B>
Operation: BINOP_LOGICAL_AND --(4)
Operation: OP_VAR_VALUE --(5)
Symbol: ptr
Block: 0x45a2a00
Operation: BINOP_EQUAL --(6)
Operation: STRUCTOP_PTR --(7)
Operation: OP_VAR_VALUE --(8)
Symbol: ptr
Block: 0x45a2a00
String: a
Operation: OP_LONG --(9)
Type: int
Constant: 0x0000000000000003
In expression <A> we should assume that t2_array is of dynamic type.
Nothing has dynamic type in expression <B>.
This is how GDB currently handles expression <A>, in all cases,
EVAL_AVOID_SIDE_EFFECTS or EVAL_NORMAL, an OP_VAR_VALUE operation
always returns the real value of the symbol, this is not forced to a
zero value even in EVAL_AVOID_SIDE_EFFECTS mode. This means that (3),
(5), and (8) will always return a real lazy value for the symbol.
However a STRUCTOP_STRUCT will always replace its result with a
non-lazy, zero value with the same type as its result. So (2) will
lookup the field ptr_2 and create a zero value with that type. In
this case the type is a pointer to a dynamic type.
Then, when we evaluate (1) to figure out the resolved type of
t2_array, we need to read the types dynamic properties. These
properties are stored in memory relative to the objects base address,
and the base address is in var8%ptr_2, which we already figured out
has the value zero. GDB then evaluates the DWARF expressions that
take the base address, add an offset and dereference. GDB then ends
up trying to access addresses like 0x16, 0x8, etc.
To fix this, I proposed changing STRUCTOP_STRUCT so that instead of
returning a zero value we instead returned the actual value
representing the structure's field in the target. My thinking was
that GDB would not try to access the value's contents unless it needed
it to resolve a dynamic type. This belief was incorrect.
Consider expression <B>. We already know that (5) and (8) will return
real values for the symbols being referenced. The BINOP_LOGICAL_AND,
operation (4) will evaluate both of its children in
EVAL_AVOID_SIDE_EFFECTS in order to get the types, this is required
for C++ operator lookup. This means that even if the value of (5)
would result in the BINOP_LOGICAL_AND returning false (say, ptr is
NULL), we still evaluate (6) in EVAL_AVOID_SIDE_EFFECTS mode.
Operation (6) will evaluate both children in EVAL_AVOID_SIDE_EFFECTS
mode, operation (9) is easy, it just returns a value with the constant
packed into it, but (7) is where the problem lies. Currently in GDB
this STRUCTOP_STRUCT will always return a non-lazy zero value of the
correct type.
When the results of (7) and (9) are back in the BINOP_LOGICAL_AND
operation (6), the two values are passed to value_equal which performs
the comparison and returns a result. Note, the two things compared
here are the immediate value (9), and a non-lazy zero value from (7).
However, with my proposed patch operation (7) no longer returns a zero
value, instead it returns a lazy value representing the actual value
in target memory. When we call value_equal in (6) this code causes
GDB to try and fetch the actual value from target memory. If `ptr` is
NULL then this will cause GDB to access some invalid address at an
offset from zero, this will most likely fail, and cause GDB to throw
an error instead of returning the expected type.
And so, we can now describe the problem that we're facing. The way
GDB's expression evaluator is currently written we assume, when in
EVAL_AVOID_SIDE_EFFECTS mode, that any value returned from a child
operation can safely have its content read without throwing an
error. If child operations start returning real values (instead of
the fake zero values), then this is simply not true.
If we wanted to work around this then we would need to rewrite almost
all operations (I would guess) so that EVAL_AVOID_SIDE_EFFECTS mode
does not cause evaluation of an operation to try and read the value of
a child operation. As an example, consider this current GDB code from
eval.c:
struct value *
eval_op_equal (struct type *expect_type, struct expression *exp,
enum noside noside, enum exp_opcode op,
struct value *arg1, struct value *arg2)
{
if (binop_user_defined_p (op, arg1, arg2))
{
return value_x_binop (arg1, arg2, op, OP_NULL, noside);
}
else
{
binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2);
int tem = value_equal (arg1, arg2);
struct type *type = language_bool_type (exp->language_defn,
exp->gdbarch);
return value_from_longest (type, (LONGEST) tem);
}
}
We could change this function to be this:
struct value *
eval_op_equal (struct type *expect_type, struct expression *exp,
enum noside noside, enum exp_opcode op,
struct value *arg1, struct value *arg2)
{
if (binop_user_defined_p (op, arg1, arg2))
{
return value_x_binop (arg1, arg2, op, OP_NULL, noside);
}
else
{
struct type *type = language_bool_type (exp->language_defn,
exp->gdbarch);
if (noside == EVAL_AVOID_SIDE_EFFECTS)
return value_zero (type, VALUE_LVAL (arg1));
else
{
binop_promote (exp->language_defn, exp->gdbarch, &arg1, &arg2);
int tem = value_equal (arg1, arg2);
return value_from_longest (type, (LONGEST) tem);
}
}
}
Now we don't call value_equal unless we really need to. However, we
would need to make the same, or similar change to almost all
operations, which would be a big task, and might not be a direction we
wanted to take GDB in.
So, for now, I'm proposing we go with the more targeted, Fortran
specific solution, that does the minimal required in order to
correctly resolve the dynamic types.
gdb/ChangeLog:
* f-exp.h (class fortran_structop_operation): New class.
* f-exp.y (exp): Create fortran_structop_operation instead of the
generic structop_operation.
* f-lang.c (fortran_undetermined::evaluate): Re-evaluate
expression as EVAL_NORMAL if the result type was dynamic so we can
extract the actual array bounds.
(fortran_structop_operation::evaluate): New function.
gdb/testsuite/ChangeLog:
* gdb.fortran/dynamic-ptype-whatis.exp: New file.
* gdb.fortran/dynamic-ptype-whatis.f90: New file.
It is not currently possible to cast some values to an rvaule
reference. This happens when simple scalar values are cast to an
rvalue reference of the same type, e.g.:
int global_var;
Then in GDB:
(gdb) p static_cast<int&&> (global_var)
Attempt to take address of value not located in memory.
Which is clearly silly.
The problem is that as part of the cast an intermediate value is
created within GDB that becomes an lval_none rather than the original
lval_memory. The casting logic basically goes like this:
The call tree that leads to the error looks like this:
value_cast
value_cast
value_ref
value_addr
error
The first value_cast call is casting the value for 'global_var' to
type 'int&&'. GDB spots that the target type is a reference, and so
calls value_cast again, this time casting 'global_var' to type 'int'.
We then call value_ref to convert the result of the second value_cast
into a reference.
Unfortunately, the second cast results in the value (for global_var)
changing from an lval_memory to an lval_none. This is because int to
int casting calls extract_unsigned_integer and then
value_from_longest.
In theory value_cast has a check at its head that should help in this
case, the code is:
if (value_type (arg2) == type)
return arg2;
However, this only works in some cases. In our case
'value_type (arg2)' will be an objfile owned type, while the type from
the expression parser 'int&&' will be gdbarch owned. The pointers
will not be equal, but the meaning of the type will be equal.
I did consider making the int to int casting case smarter, but this
obviously is only one example. We must also consider things like
float to float, or pointer to pointer....
So, I instead decided to try and make the initial check smarter.
Instead of a straight pointer comparison, I now propose that we use
types_deeply_equal. If this is true then we are casting something
back to its current type, in which case we can preserve the lval
setting by using value_copy.
gdb/ChangeLog:
* valops.c (value_cast): Call value_deeply_equal before performing
any cast.
gdb/testsuite/ChangeLog:
* gdb.cp/rvalue-ref-params.cc (f3): New function.
(f4): New function.
(global_int): New global variable.
(global_float): Likeiwse.
(main): Call both new functions.
* gdb.cp/rvalue-ref-params.exp: Add new tests.
DWARF allows .dwo file paths to be relative rather than absolute.
When they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative.
In this case, GDB currently searches relative to its current working
directory, i.e. the directory from which the debugger was launched,
but not relative to the directory containing the built binary. This
cannot be right, as the compiler, when generating the relative paths,
knows where it's building the binary but can have no idea where the
debugger will be launched.
The correct thing is to add the directory containing the binary to the
search paths used for resolving relative locations of dwo files. That
is what this patch does.
gdb/ChangeLog:
* dwarf2/read.c (try_open_dwop_file): Add path for the binary to
the search paths used resolve relative location of .dwo file.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/fission-relative-dwo.c: New file.
* gdb.dwarf2/fission-relative-dwo.exp: New file.
This commit fixes fission support in the Dwarf assembler. I added the
new test gdb.dwarf2/fission-absolute-dwo.exp which is a simple example
of using the fission support. I also rewrote the existing test
gdb.dwarf2/fission-multi-cu.exp to use the new functionality (instead
of using an x86-64 only assembler file).
To better support compiling the assembler files produced by the Dwarf
assembler I have added the new proc build_executable_and_dwo_files in
lib/dwarf.exp, this replaces build_executable_from_fission_assembler,
all the tests that used the old proc have been updated. Where the old
proc assumed a single .S source file which contained the entire test,
the new proc allows for multiple source files.
The Dwarf assembler already had some fission support, however, this
was not actually used in any tests, and when I tried using it there
were a few issues.
The biggest change is that we now generate DW_FORM_GNU_addr_index
instead of DW_FORM_addr for the low and high pc in
_handle_macro_at_range, support for the DW_FORM_GNU_addr_index is new
in this commit.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/fission-absolute-dwo.c: New file.
* gdb.dwarf2/fission-absolute-dwo.exp: New file.
* gdb.dwarf2/fission-base.exp: Use build_executable_and_dwo_files
instead of build_executable_from_fission_assembler.
* gdb.dwarf2/fission-loclists-pie.exp: Likewise.
* gdb.dwarf2/fission-loclists.exp: Likewise.
While messing with the Dwarf assembler (gdb/testsuite/lib/dwarf.exp) I
managed to create an ELF which made use of DW_FORM_strp, but didn't
include a .debug_str section.
When I started GDB on this ELF, GDB crashed. I would have expected to
get an error instead.
I tracked this down to an unfortunate design choice in
dwarf2_section_info, a class which wraps around a bfd section, and is
used for reading in debug information. GBB creates many
dwarf2_section_info objects, one for each debug section that might
need to be read, then as we find the input bfd sections we associate
them with the corresponding dwarf2_section_info.
If no matching input bfd section is found then the dwarf2_section_info
is left in an unassociated state, its internal bfd section pointer is
null.
If later GDB tries to read content from the dwarf2_section_info, for
example, which trying to read the string associated with DW_FORM_strp,
we spot that there is no associated bfd section and issue an error
message.
To make the users life easier, the error message includes the section
name being looked for, and the bfd from which the section was
obtained.
However, we get the section name by calling bfd_section_name on the
associated section, and we get the bfd filename by calling
bfd_get_filename on the owner of the associated section.
Of course, if there is no associated section then both the calls
bfd_section_name and dwarf2_section_info::get_bfd_owner will result in
undefined behaviour (e.g. a crash).
The solution I propose in this patch is, I know, not ideal. I simply
spot the case where there is no associated section, and print a
simpler error message, leaving out the section name and filename.
A better solution would involve redesigning dwarf2_section_info, we
could associate each dwarf2_section_info with the initial bfd being
parsed. We would then display this filename if there's nothing better
to display (e.g. if we find a section in a dwo/dwp split dwarf file
then we would probably use that filename in preference).
Each dwarf2_section_info could also have the concept of the default
section name that would be read for that section, for example, string
data might appear in ".debug_str" or ".zdebug_str", but if neither is
found, then it would probably be OK to just say ".debug_str" is
missing.
Anyway, I didn't do any of that redesign, I just wanted to stop GDB
crashing for now, so instead we get this:
Dwarf Error: DW_FORM_strp used without required section
Which isn't the best, but in context, isn't too bad:
Reading symbols from /path/to/executable...
Dwarf Error: DW_FORM_strp used without required section
(No debugging symbols found in /path/to/executable)
I also added some asserts into dwarf2_section_info which should
trigger before GDB crashes in future, if we trigger any other bad
paths through this code.
And there's a test for the specific issue I hit.
gdb/ChangeLog:
* dwarf2/section.c (dwarf2_section_info::get_bfd_owner): Add an
assert.
(dwarf2_section_info::get_file_name): Add an assert.
(dwarf2_section_info::read_string): Display a minimal, sane error
when the dwarf2_section_info is not associated with a bfd section.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-using-debug-str.exp: Add an additional test.
It was reported on IRC that using gdb.parameter('data-directory')
doesn't work correctly.
The problem is that the data directory is stored in 'gdb_datadir',
however the set/show command is associated with a temporary
'staged_gdb_datadir'.
When the user does 'set data-directory VALUE', the VALUE is stored in
'staged_gdb_datadir' by GDB, then set_gdb_datadir is called. This in
turn calls set_gdb_data_directory to copy the value from
staged_gdb_datadir into gdb_datadir.
However, set_gdb_data_directory will resolve relative paths, so the
value stored in gdb_datadir might not match the value in
staged_gdb_datadir.
The Python gdb.parameter API fetches the parameter values by accessing
the variable associated with the show command, so in this case
staged_gdb_datadir. This causes two problems:
1. Initially staged_gdb_datadir is NULL, and remains as such until the
user does 'set data-directory VALUE' (which might never happen), but
gdb_datadir starts with GDB's default data-directory value. So
initially from Python gdb.parameter('data-directory') will return the
empty string, even though at GDB's CLI 'show data-directory' prints a
real path.
2. If the user does 'set data-directory ./some/relative/path', GDB
will resolve the relative path, thus, 'show data-directory' at the CLI
will print an absolute path. However, the value is staged_gdb_datadir
will still be the relative path, and gdb.parameter('data-directory')
from Python will return the relative path.
In this commit I fix both of these issues by:
1. Initialising the value in staged_gdb_datadir based on the initial
value in gdb_datadir, and
2. In set_gdb_datadir, after calling set_gdb_data_directory, I copy
the value in gdb_datadir back into staged_gdb_datadir.
With these two changes in place the value in staged_gdb_datadir should
always match the value in gdb_datadir, and accessing data-directory
from Python should now work correctly.
gdb/ChangeLog:
* top.c (staged_gdb_datadir): Update comment.
(set_gdb_datadir): Copy the value of gdb_datadir back into
staged_datadir.
(init_main): Initialise staged_gdb_datadir.
gdb/testsuite/ChangeLog:
* gdb.python/py-parameter.exp: Add test for reading data-directory
using gdb.parameter API.
When running test-case gdb.opt/inline-cmds.exp, we run into this KFAIL with
gcc:
...
Breakpoint 7, main () at gdb.opt/inline-cmds.c:71^M
71 result = 0; /* set breakpoint 3 here */^M
(gdb) PASS: gdb.opt/inline-cmds.exp: continue to breakpoint: consecutive func1
next^M
73 func1 (); /* first call */^M
(gdb) PASS: gdb.opt/inline-cmds.exp: next to first func1
next^M
75 marker ();^M
(gdb) KFAIL: gdb.opt/inline-cmds.exp: next to second func1 (PRMS: gdb/25884)
...
while with clang we have instead:
...
next^M
74 func1 (); /* second call */^M
(gdb) PASS: gdb.opt/inline-cmds.exp: next to second func1
...
The relevant bit of the test source is here in inline-cmds.c:
...
71 result = 0; /* set breakpoint 3 here */
72
73 func1 (); /* first call */
74 func1 (); /* second call */
75 marker ();
...
with func1 defined as:
...
33 inline __attribute__((always_inline)) int func1(void)
34 {
35 bar ();
36 return x * y;
37 }
...
The corresponding insns are:
...
40050b: movl $0x0,0x200b1f(%rip) # 601034 <result>
400515: callq 40057b <bar>
40051a: callq 40057b <bar>
40051f: callq 400596 <marker>
...
and the line number info is:
...
Line number Starting address View Stmt
71 0x40050b x
35 0x400515 x
75 0x40051f x
...
The line number info is missing an entry for the insn at 40051a, and that is
causing the FAIL. This is a gcc issue, filed as PR gcc/98780 -" Missing line
table entry for inlined stmt at -g -O0".
[ For contrast, with clang we have an extra entry:
...
Line number Starting address View Stmt
71 0x40050b x
35 0x400515 x
35 0x40051a
75 0x40051f x
...
though it appears to be missing the start-of-statement marker. ]
However, there is debug info that indicates that the insn at 40051a is not
part of the line table entry for the insn at 400515:
...
<2><1c4>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
<1c5> DW_AT_abstract_origin: <0x2a2>
<1c9> DW_AT_low_pc : 0x400515
<1d1> DW_AT_high_pc : 0x5
<1d9> DW_AT_call_file : 1
<1da> DW_AT_call_line : 73
<2><1db>: Abbrev Number: 8 (DW_TAG_inlined_subroutine)
<1dc> DW_AT_abstract_origin: <0x2a2>
<1e0> DW_AT_low_pc : 0x40051a
<1e8> DW_AT_high_pc : 0x5
<1f0> DW_AT_call_file : 1
<1f1> DW_AT_call_line : 74
...
and indeed lldb manages to "next" from line 73 to line 74.
Work around the missing line table entry, by using the inline frame info to
narrow the stepping range in prepare_one_step.
Tested on x86_64-linux.
gdb/ChangeLog:
2021-04-06 Tom de Vries <tdevries@suse.de>
PR breakpoints/25884
* infcmd.c (prepare_one_step): Using inline frame info to narrow
stepping range.
gdb/testsuite/ChangeLog:
2021-04-06 Tom de Vries <tdevries@suse.de>
PR breakpoints/25884
* gdb.opt/inline-cmds.exp: Remove kfail.
When running test-case gdb.threads/gcore-thread.exp on openSUSE Tumbleweed,
I run into these XFAILs:
...
XFAIL: gdb.threads/gcore-thread.exp: clear __stack_user.next
XFAIL: gdb.threads/gcore-thread.exp: clear stack_used.next
...
Apart from the xfail, the test-case also sets core0file to "":
...
-re "No symbol \"${symbol}\" in current context\\.\r\n$gdb_prompt $" {
xfail $test
# Do not do the verification.
set core0file ""
}
...
After which we run into this FAIL, because gdb_core_cmd fails to load a
core file called "":
...
(gdb) core ^M
No core file now.^M
(gdb) FAIL: gdb.threads/gcore-thread.exp: core0file: \
re-load generated corefile
...
Fix this FAIL by skipping gdb_core_cmd if the core file is "".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2021-04-06 Tom de Vries <tdevries@suse.de>
PR testsuite/27691
* gdb.threads/gcore-thread.exp: Don't call gdb_core_cmd with core
file "".
In commit cfcbd506fb "[gdb/testsuite] Ignore DEBUGINFOD_URLS" I added
unsetting of env(DEBUGINFOD_URLS), but it doesn't work because I forgot to
add :: in front.
Fix this, and rewrite using "unset -nocomplain" instead of unsetenv, which
allows us to drop the "info exists" test.
2021-04-01 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (default_gdb_init): Use ::env. Use unset
-nocomplain ::env(V) instead of unsetenv V.
I had written a DWARF location expression like
DW_OP_const1u
DW_OP_stack_value
... and was surprised to see that the DW_OP_stack_value didn't appear
in the "readelf" output.
The problem here is that DW_OP_const1u requires an operand, but
neither the DWARF assembler nor gas diagnosed this problem.
This patch adds some checking to Dwarf::_location to try to avoid this
in the future. The checking is done via a helper proc that also
dissects the argument list and sets an array in the caller's frame.
gdb/testsuite/ChangeLog
2021-03-31 Tom Tromey <tromey@adacore.com>
* lib/dwarf.exp (Dwarf::_get_args): New proc.
(Dwarf::_location): Use it.
On openSUSE Tumbleweed, DEBUGINFOD_URLS is now defined by default:
...
$ echo $DEBUGINFOD_URLS
https://debuginfod.opensuse.org/
...
With DEBUGINFOD_URLS defined we run into:
...
FAIL: gdb.mi/mi-sym-info.exp: List all functions from debug information only \
(timeout)
...
as reported in PR27667.
There's a latency of ~0.5s per request, which is ok-ish for interactive usage.
But the symbol-info-functions command ends up issuing 21 source requests,
which means we easily run into the 10s timeout.
Fix this by unsetting DEBUGINFOD_URLS in default_gdb_init.
gdb/testsuite/ChangeLog:
2021-03-31 Tom de Vries <tdevries@suse.de>
PR testsuite/27667
* lib/gdb.exp (default_gdb_init): Unset DEBUGINFOD_URLS.
New in v2:
- Disable sharing only for -readnow objfiles, not all objfiles.
As described in PR 27541, we hit an internal error when loading a binary
the standard way and then loading it with the -readnow option:
$ ./gdb -nx -q --data-directory=data-directory ~/a.out -ex "set confirm off" -ex "file -readnow ~/a.out"
Reading symbols from /home/simark/a.out...
Reading symbols from ~/a.out...
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8098: internal-error: void create_all_comp_units(dwarf2_per_objfile*): Assertion `per_objfile->per_bfd->all_comp_units.empty ()' failed.
This is a recurring problem that exposes a design issue in the DWARF
per-BFD sharing feature. Things work well when loading a binary with
the same method (with/without index, with/without readnow) twice in a
row. But they don't work so well when loading a binary with different
methods. See this previous fix, for example:
efb763a5ea ("gdb: check for partial symtab presence in dwarf2_initialize_objfile")
That one handled the case where the first load is normal (uses partial
symbols) and the second load uses an index.
The problem is that when loading an objfile with a method A, we create a
dwarf2_per_bfd and some dwarf2_per_cu_data and initialize them with the
data belonging to that method. When loading another obfile sharing the
same BFD but with a different method B, it's not clear how to re-use the
dwarf2_per_bfd/dwarf2_per_cu_data previously created, because they
contain the data specific to method A.
I think the most sensible fix would be to not share a dwarf2_per_bfd
between two objfiles loaded with different methods. That means that two
objfiles sharing the same BFD and loaded the same way would share a
dwarf2_per_bfd. Two objfiles sharing the same BFD but loaded with
different methods would use two different dwarf2_per_bfd structures.
However, this isn't a trivial change. So to fix the known issue quickly
(including in the gdb 10 branch), this patch just disables all
dwarf2_per_bfd sharing for objfiles using READNOW.
Generalize the gdb.base/index-cache-load-twice.exp test to test all
the possible combinations of loading a file with partial symtabs, index
and readnow. Move it to gdb.dwarf2, since it really exercises features
of the DWARF reader.
gdb/ChangeLog:
PR gdb/27541
* dwarf2/read.c (dwarf2_has_info): Don't share dwarf2_per_bfd
with objfiles using READNOW.
gdb/testsuite/ChangeLog:
PR gdb/27541
* gdb.base/index-cache-load-twice.exp: Remove.
* gdb.base/index-cache-load-twice.c: Remove.
* gdb.dwarf2/per-bfd-sharing.exp: New.
* gdb.dwarf2/per-bfd-sharing.c: New.
Change-Id: I9ffcf1e136f3e75242f70e4e58e4ba1fd3083389
Since commit 27012aba8a "Remove Irix 6 workaround from DWARF abbrev reader"
we have:
...
(gdb) file dw2-cu-size^M
Reading symbols from dw2-cu-size...^M
DW_FORM_strp pointing outside of .debug_str section [in module dw2-cu-size]^M
(No debugging symbols found in dw2-cu-size)^M
(gdb) ptype noloc^M
No symbol table is loaded. Use the "file" command.^M
(gdb) FAIL: gdb.dwarf2/dw2-cu-size.exp: ptype noloc
...
The problem is a missing .debug_abbrev terminator in dw2-cu-size.S, which
causes the .debug_abbrev contribution to be merged with the next:
...
Number TAG (0x9b)
1 DW_TAG_compile_unit [has children]
DW_AT_name DW_FORM_string
DW_AT_producer DW_FORM_string
DW_AT_language DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
2 DW_TAG_variable [no children]
DW_AT_name DW_FORM_string
DW_AT_type DW_FORM_ref4
DW_AT_external DW_FORM_flag
DW_AT value: 0 DW_FORM value: 0
3 DW_TAG_base_type [no children]
DW_AT_name DW_FORM_string
DW_AT_byte_size DW_FORM_data1
DW_AT_encoding DW_FORM_data1
DW_AT value: 0 DW_FORM value: 0
4 DW_TAG_const_type [no children]
DW_AT_type DW_FORM_ref_udata
DW_AT value: 0 DW_FORM value: 0
1 DW_TAG_compile_unit [has children]
DW_AT_producer DW_FORM_strp
DW_AT_language DW_FORM_data1
DW_AT_name DW_FORM_strp
DW_AT_comp_dir DW_FORM_strp
DW_AT_low_pc DW_FORM_addr
DW_AT_high_pc DW_FORM_data8
DW_AT_stmt_list DW_FORM_sec_offset
DW_AT value: 0 DW_FORM value: 0
...
and consequently, abbreviation code 1 no longer refers to a unique entry.
The eventually causes us to access the first attribute of this DIE:
...
<0><124>: Abbrev Number: 1 (DW_TAG_compile_unit)
<125> DW_AT_name : file1.txt
<12f> DW_AT_producer : GNU C 3.3.3
<13b> DW_AT_language : 1 (ANSI C)
...
which has form DW_FORM_string, using DW_FORM_strp.
Fix this by adding the missing .debug_abbrev terminator in dw2-cu-size.S.
gdb/testsuite/ChangeLog:
2021-03-30 Tom de Vries <tdevries@suse.de>
PR testsuite/27604
* gdb.dwarf2/dw2-cu-size.S: Add missing .debug_abbrev terminator.
This test causes several timeouts for Clang, taking too long time to
finish. The reason is, for an infinite loop of the form
while(1); /* suppose this is line 30. */
Clang generates code that looks like
0x00000000004004d4 <+4>: jmp 0x4004d9 <loop+9>
0x00000000004004d9 <+9>: jmp 0x4004d9 <loop+9>
So, the real loop is the instruction at address 0x4004d9. But a
breakpoint that's defined at the loop line (assume line 30 in this
case) is inserted at address 0x4004d4.
(gdb) break 30
Breakpoint 1 at 0x4004d4: file test.c, line 30.
Therefore, continuing a thread that was spinning on the loop does not hit
the breakpoint. The bug is reported at
https://bugs.llvm.org/show_bug.cgi?id=49614
Tweak the infinite loop to spin on a variable to avoid this bug. The
test is unrelated to the bug.
gdb/testsuite/ChangeLog:
2021-03-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.mi/user-selected-context-sync.exp: Spin on a variable in
the infinite loop to avoid a Clang bug.
Resolve some duplicate test name warnings in gdb.arch/powerpc-*.exp
tests by either extending the existing test names, or providing a new
test name.
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-disassembler-options.exp: Extend some test
names for uniqueness.
* gdb.arch/powerpc-fpscr-gcore.exp: Add more test names for
uniqueness.
This commit adds a couple of tests to the python pretty printer
testing.
I've added a test for the 'array' display hint. This display hint is
tested by gdb.python/py-mi.exp, however, the MI testing is done via
the varobj interface, and this code makes its own direct calls to the
Python pretty printers from gdb/varobj.c. What this means is that the
interface to the pretty printers in gdb/python/py-prettyprint.c is not
tested for the 'array' display hint path.
I also added a test for what happens when the display_hint method
raises an exception. There wasn't a bug that inspired this test, just
while adding the previous test I thought, I wonder what happens if...
The current behaviour of GDB seems reasonable, GDB displays the Python
exception, and then continues printing the value as if display_hint
had returned None. I added a test to lock in this behaviour.
gdb/testsuite/ChangeLog:
* gdb.python/py-prettyprint.c (struct container): Add 'is_array_p'
member.
(make_container): Initialise is_array_p.
* gdb.python/py-prettyprint.exp: Add new tests.
* gdb.python/py-prettyprint.py (ContainerPrinter.display_hint):
Check is_array_p and possibly return 'array'.
This commit resolves the remaining duplicate test names in
gdb.cp/*.exp. These are all the easy duplicates, I'm either giving
tests a new, unique name, extending an existing name to make it
unique, or changing an existing name to better reflect what the test
is actually doing, and thus, making this test name unique.
There should be no change in what is tested after this commit.
gdb/testsuite/ChangeLog:
* gdb.cp/breakpoint.exp: Extend test names to make them unique.
* gdb.cp/casts.exp: Give tests unique names.
* gdb.cp/filename.exp: Likewise.
* gdb.cp/gdb2495.exp: Likewise.
* gdb.cp/mb-ctor.exp: Extend test names to make them unique.
* gdb.cp/misc.exp: Rename test to make it unique.
* gdb.cp/nsnested.exp: Give tests unique names.
* gdb.cp/ovldbreak.exp: Likewise.
* gdb.cp/pr17494.exp: Rename test to reflect what is actually
being tested. This also removes the duplicate test name.
* gdb.cp/ref-types.exp: Likewise.
* gdb.cp/temargs.exp: Likewise.
While resolving duplicate test names I spotted that a test in
gdb.cp/cplusfuncs.exp included an unescaped '[]'. In TCL square
brackets enclose expressions to evaluate, and so in this case, where
there is no enclosed expression, this just evaluates to the empty
string.
This clearly was not what the test intended, so in this commit I have
escaped the square brackets. This has extended the test coverage.
gdb/testsuite/ChangeLog:
* gdb.cp/cplusfuncs.exp (test_paddr_operator_functions): Escape
square brackets in test.
I wanted to remove the duplicate test name from gdb.cp/maint.exp. In
this test we run some checks against different operator names. For
one operator we test with a variable number of spaces. However, we
were accidentally testing the one space version twice, and the zero
space version not at all, leading to a duplicate test name.
I could have just changed the duplicate one space version into the
missing zero space version, but I thought it would be neater to wrap
multiple tests in a loop, and check all operators with either zero,
one, or two spaces.
These tests are super quick so take almost no extra time, and this
gives marginally more test coverage.
gdb/testsuite/ChangeLog:
* gdb.cp/maint.exp (test_first_component): Run more tests with a
variable number of spaces, this removes the duplicate testing of
'operator ->' which existed before.
The test gdb.cp/gdb2384.exp contains some duplicate test names, and
also some test names with a string inside parentheses at the end. In
order to resolve the duplicates the obvious choice would be to add yet
more strings inside parentheses at the end of names, however, this is
discouraged in our test naming scheme.
The string in parentheses originates from a comment in the test source
code, which naturally leads to including this comment in the test
name.
In this commit I have changed the comment in the test source to remove
the string in parentheses, I then rename the tests in the .exp script
to match, making sure that all test names are unique.
There should be no change in test coverage after this commit.
gdb/testsuite/ChangeLog:
* gdb.cp/gdb2384.cc (main): Change comments used for breakpoints.
* gdb.cp/gdb2384.exp: Change and extend test names to avoid
duplicates, and also to avoid having a string inside parentheses
at the end of test names.
In trying to resolve the duplicate test names for the
gdb.cp/nsusing.exp script, I ended up giving the test script a serious
spring clean.
This reverts some of the changes introduced in commit df83a9bf8b,
but I don't think that we have lost any testing.
The test program is made of many functions, the test script wants to
stop in different functions and check which symbols are in scope.
Previously the test script would either restart GDB completely in
order to "progress" to the next function, or the script would restart
the test program using 'runto'.
In this commit I have reordered the steps of the test to correspond to
program order, I then progress through the test program once by just
placing a breakpoint and then continuing. As I said, the test is
checking which symbols are in scope at each location, so the exact
order of the tests doesn't matter, so long as we check the correct
symbols at each location.
I have also given the comments capital letters and full stops, and
re-wrapped them to a more sensible line length.
There was a duplicate test block introduced in the df83a9bf8b
commit which I have removed in this commit, this duplicate code was
responsible for one of the duplicate test names.
The other duplicate test name was due to the same command being run at
different locations, in this case I just gave the two tests explicit,
unique, names.
gdb/testsuite/ChangeLog:
* gdb.cp/nsusing.exp: Rewrite test, remove a duplicate test block.
Avoid repeated uses of 'runto', and instread just progress once
through the test stopping at different breakpoints. Give comments
a capital letter and full stop. Give duplicate tests unique names.
When testing with "maint set target-non-stop on",
gdb.server/bkpt-other-inferior.exp sometimes fails like so:
(gdb) inferior 2
[Switching to inferior 2 [process 368191] (<noexec>)]
[Switching to thread 2.1 (Thread 368191.368191)]
[remote] Sending packet: $m7ffff7fd0100,1#5b
[remote] Packet received: 48
[remote] Sending packet: $m7ffff7fd0100,1#5b
[remote] Packet received: 48
[remote] Sending packet: $m7ffff7fd0100,9#63
[remote] Packet received: 4889e7e8e80c000049
#0 0x00007ffff7fd0100 in ?? ()
(gdb) PASS: gdb.server/bkpt-other-inferior.exp: inf 2: switch to inferior
break -q main
Breakpoint 2 at 0x1138: file /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.server/server.c, line 21.
(gdb) PASS: gdb.server/bkpt-other-inferior.exp: inf 2: set breakpoint
delete breakpoints
Delete all breakpoints? (y or n) y
(gdb) [remote] wait: enter
[remote] wait: exit
FAIL: gdb.server/bkpt-other-inferior.exp: inf 2: delete all breakpoints in delete_breakpoints (timeout)
ERROR: breakpoints not deleted
Remote debugging from host ::1, port 55876
monitor exit
The problem is here:
(gdb) [remote] wait: enter
The testcase isn't expecting any output after the prompt.
Why is that "[remote] wait" output? What happens is that "delete
breakpoints" queries the user, and `query` disables/reenables target
async, which results in the remote target's async event handler ending
up marked:
(top-gdb) bt
#0 mark_async_event_handler (async_handler_ptr=0x556bffffffff) at ../../src/gdb/async-event.c:295
#1 0x0000556bf71b711f in infrun_async (enable=1) at ../../src/gdb/infrun.c:119
#2 0x0000556bf7471387 in target_async (enable=1) at ../../src/gdb/target.c:3684
#3 0x0000556bf748a0bd in gdb_readline_wrapper_cleanup::~gdb_readline_wrapper_cleanup (this=0x7ffe3cf30eb0, __in_chrg=<optimized out>) at ../../src/gdb/top.c:1074
#4 0x0000556bf74874e2 in gdb_readline_wrapper (prompt=0x556bfa17da60 "Delete all breakpoints? (y or n) ") at ../../src/gdb/top.c:1096
#5 0x0000556bf75111c5 in defaulted_query(const char *, char, typedef __va_list_tag __va_list_tag *) (ctlstr=0x556bf7717f34 "Delete all breakpoints? ", defchar=0 '\000', args=0x7ffe3cf31020) at ../../src/gdb/utils.c:893
#6 0x0000556bf751166f in query (ctlstr=0x556bf7717f34 "Delete all breakpoints? ") at ../../src/gdb/utils.c:985
#7 0x0000556bf6f11404 in delete_command (arg=0x0, from_tty=1) at ../../src/gdb/breakpoint.c:13500
...
... which then later results in a target_wait call:
(top-gdb) bt
#0 remote_target::wait_ns (this=0x7ffe3cf30f80, ptid=..., status=0xde530314f0802800, options=...) at ../../src/gdb/remote.c:7937
#1 0x0000556bf7369dcb in remote_target::wait (this=0x556bfa0b2180, ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/remote.c:8173
#2 0x0000556bf745e527 in target_wait (ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/target.c:2000
#3 0x0000556bf71be686 in do_target_wait_1 (inf=0x556bfa1573d0, ptid=..., status=0x7ffe3cf31568, options=...) at ../../src/gdb/infrun.c:3463
#4 0x0000556bf71be88b in <lambda(inferior*)>::operator()(inferior *) const (__closure=0x7ffe3cf31320, inf=0x556bfa1573d0) at ../../src/gdb/infrun.c:3526
#5 0x0000556bf71bebcd in do_target_wait (wait_ptid=..., ecs=0x7ffe3cf31540, options=...) at ../../src/gdb/infrun.c:3539
#6 0x0000556bf71bf97b in fetch_inferior_event () at ../../src/gdb/infrun.c:3879
#7 0x0000556bf71a27f8 in inferior_event_handler (event_type=INF_REG_EVENT) at ../../src/gdb/inf-loop.c:42
#8 0x0000556bf71cc8b7 in infrun_async_inferior_event_handler (data=0x0) at ../../src/gdb/infrun.c:9220
#9 0x0000556bf6ecb80f in check_async_event_handlers () at ../../src/gdb/async-event.c:327
#10 0x0000556bf76b011a in gdb_do_one_event () at ../../src/gdbsupport/event-loop.cc:216
...
... which returns TARGET_WAITKIND_IGNORE.
Fix this by only enabling remote output around setting the breakpoint.
gdb/testsuite/ChangeLog:
* gdb.server/bkpt-other-inferior.exp: Only enable remote output
around setting the breakpoint.
Change-Id: I2fd152fd9c46b1c5e7fa678cc4d4054dac0b2bd4
Running gdb.server/stop-reply-no-thread-multi.exp with "maint set
target-non-stop on" occasionally hit an internal error like this:
...
continue
Continuing.
warning: multi-threaded target stopped without sending a thread-id, using first non-exited thread
/home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:291: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
This is a bug, please report it.
FAIL: gdb.server/stop-reply-no-thread-multi.exp: to_disable=Tthread: continue until exit (GDB internal error)
The backtrace looks like this:
...
#5 0x0000560357b0879c in internal_error (file=0x560357be6c18 "/home/pedro/gdb/binutils-gdb/src/gdb/inferior.c", line=291, fmt=0x560357be6b21 "%s: Assertion `%s' failed.") at /home/pedro/gdb/binutils-gdb/src/gdbsupport/errors.cc:55
#6 0x000056035762061b in find_inferior_pid (targ=0x5603596e9560, pid=0) at /home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:291
#7 0x00005603576206e6 in find_inferior_ptid (targ=0x5603596e9560, ptid=...) at /home/pedro/gdb/binutils-gdb/src/gdb/inferior.c:305
#8 0x00005603577d43ed in remote_target::check_pending_events_prevent_wildcard_vcont (this=0x5603596e9560, may_global_wildcard=0x7fff84fb05f0) at /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:7215
#9 0x00005603577d2a9c in remote_target::commit_resumed (this=0x5603596e9560) at /home/pedro/gdb/binutils-gdb/src/gdb/remote.c:6680
...
pid is 0 in this case because the queued event is a process exit event
with no pid associated:
(top-gdb) p event->ws
During symbol reading: .debug_line address at offset 0x563c9a is 0 [in module /home/pedro/gdb/binutils-gdb/build/gdb/gdb]
$1 = {kind = TARGET_WAITKIND_EXITED, value = {integer = 0, sig = GDB_SIGNAL_0, related_pid = {m_pid = 0, m_lwp = 0, m_tid = 0}, execd_pathname = 0x0, syscall_number = 0}}
(top-gdb)
This fixes it, and adds a "maint set target-non-stop on/off" axis to the testcase.
gdb/ChangeLog:
* remote.c
(remote_target::check_pending_events_prevent_wildcard_vcont):
Check whether the event's ptid is not null_ptid before looking up
the corresponding inferior.
gdb/testsuite/ChangeLog:
* gdb.server/stop-reply-no-thread-multi.exp (run_test): Add
"target_non_stop" parameter and use it.
(top level): Add "maint set target-non-stop on/off" testing axis.
Change-Id: Ia30cf275305ee4dcbbd33f731534cd71d1550eaa
I ran into a new failure in gdb.base/gdb-caching-proc.exp:
FAIL: gdb.base/gdb-caching-proc.exp: supports_memtag: initial: memory-tag check
This is a failure from the `supports_memtag` proc added recently (this
new proc is in lib/gdb.exp).
The problem here is that `supports_memtag` is hitting one of the
default error cases in gdb_test_multiple, specifically it is finding a
$gdb_prompt left unmatched from an earlier call to gdb_test_multiple.
Looking back through the test output I found that the problem is the
proc `gnat_runtime_has_debug_info` in lib/ada.exp. This proc is not
matching the trailing $gdb_prompt. This leaves the prompt in the
expect buffer, then when we run `supports_memtag` it sees the prompt
and thinks that the test completed with no output.
Fixed by making use of `-wrap` in `gnat_runtime_has_debug_info` to
ensure the trailing prompt gets matched.
gdb/testsuite/ChangeLog:
* lib/ada.exp (gnat_runtime_has_debug_info): Use -wrap with
gdb_test_multiple.
Add an AArch64-specific test and a more generic memory tagging test that
other architectures can run.
Even though architectures not supporting memory tagging can run the memory
tagging tests, the runtime check will make the tests bail out early, as it
would make no sense to proceed without proper support.
It is also tricky to do any further runtime tests for memory tagging, given
we'd need to deal with tags, and those are arch-specific. Therefore the
test in gdb.base is more of a smoke test.
If an architecture wants to implement memory tagging, then it makes sense to
have tests within gdb.arch instead.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-mte.c: New file.
* gdb.arch/aarch64-mte.exp: New test.
* gdb.base/memtag.c: New file.
* gdb.base/memtag.exp: New test.
* lib/gdb.exp (supports_memtag): New function.
Extend the "x" and "print" commands to make use of memory tagging
functionality, if supported by the architecture.
The "print" command will point out any possible tag mismatches it finds
when dealing with pointers, in case such a pointer is tagged. No additional
modifiers are needed.
Suppose we have a pointer "p" with value 0x1234 (logical tag 0x0) and that we
have an allocation tag of 0x1 for that particular area of memory. This is the
expected output:
(gdb) p/x p
Logical tag (0x0) does not match the allocation tag (0x1).
$1 = 0x1234
The "x" command has a new 'm' modifier that will enable displaying of
allocation tags alongside the data dump. It will display one allocation
tag per line.
AArch64 has a tag granule of 16 bytes, which means we can have one tag for
every 16 bytes of memory. In this case, this is what the "x" command will
display with the new 'm' modifier:
(gdb) x/32bxm p
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x01 0x02 0x00 0x00 0x00 0x00 0x00 0x00
0x123c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x124c: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
(gdb) x/4gxm a
<Allocation Tag 0x1 for range [0x1230,0x1240)>
0x1234: 0x0000000000000201 0x0000000000000000
<Allocation Tag 0x1 for range [0x1240,0x1250)>
0x1244: 0x0000000000000000 0x0000000000000000
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* printcmd.c (decode_format): Handle the 'm' modifier.
(do_examine): Display allocation tags when required/supported.
(should_validate_memtags): New function.
(print_command_1): Display memory tag mismatches.
* valprint.c (show_memory_tag_violations): New function.
(value_print_option_defs): Add new option "memory-tag-violations".
(user_print_options) <memory_tag_violations>: Initialize to 1.
* valprint.h (struct format_data) <print_tags>: New field.
(value_print_options) <memory_tag_violations>: New field.
gdb/testsuite/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* gdb.base/options.exp: Adjust for new print options.
* gdb.base/with.exp: Likewise.
Replace an abort call in process_psymtab_comp_unit with a real error,
and add a test to cover this case. The case is question is when badly
formed DWARF is missing a DW_TAG_compile_unit, DW_TAG_partial_unit, or
DW_TAG_type_unit as its top level tag.
I then tested with --target_board=readnow and added additional code to
also validate the top-level tag in this case.
I added an assert that would trigger for the readnow case before I
added the fix. I suspect there's lots of places where badly formed
DWARF could result in the builder being nullptr when it shouldn't be,
but I only added this one assert, as this is the one that would have
helped me in this case.
gdb/ChangeLog:
* dwarf2/read.c (process_psymtab_comp_unit): Replace abort with an
error.
(process_full_comp_unit): Validate the top-level tag before
processing the first DIE.
(read_func_scope): Ensure we have a valid builder.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-missing-cu-tag.c: New file.
* gdb.dwarf2/dw2-missing-cu-tag.exp: New file.
When handling DWARF attributes of the form DW_FORM_strp the strings
should be placed in the .debug_str section, not .debug_string as they
currently are by the DWARF assembler (in lib/dwarf.exp).
I've added a test. This is as much to test the DWARF generator as it
is to test GDB as GCC makes frequent use of DW_FORM_strp so we can be
pretty sure this part of GDB is already well tested.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-using-debug-str.c: New file.
* gdb.dwarf2/dw2-using-debug-str.exp: New file.
* lib/dwarf.exp (Dwarf::DW_FORM_strp): Create .debug_str section,
not .debug_string.
This moves all the psymtab statistics printing code form symmisc.c to
psymtab.c. This changes the formatting of the output a little, but
considering that it is a maint command (and, I assume, a rarely used
one), this seems fine to me.
This change helps further dissociate the psymtab from the objfile. In
the end there will be no direct connect -- only via the
quick_symbol_functions interface.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (dwarf2_base_index_functions::print_stats): Add
print_bcache parameter.
* symfile-debug.c (objfile::print_stats): Add print_bcache
parameter.
* quick-symbol.h (struct quick_symbol_functions)
<print_stats>: Add print_bcache parameter.
* symmisc.c (print_symbol_bcache_statistics, count_psyms): Move
code to psymtab.c.
(print_objfile_statistics): Move psymtab code to psymtab.c.
* psymtab.c (count_psyms): Move from symmisc.c.
(psymbol_functions::print_stats): Print partial symbol and bcache
statistics. Add print_bcache parameter.
* objfiles.h (print_symbol_bcache_statistics): Don't declare.
(struct objfile) <print_stats>: Add print_bcache parameter.
* maint.c (maintenance_print_statistics): Update.
gdb/testsuite/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* gdb.base/maint.exp: Update "maint print statistics" output.
We're currently seeing testing of native-extended-gdbserver hang while
testing the x86_64 architecture on both Fedora 34 and Fedora Rawhide.
The test responsible for the hang is gdb.threads/fork-plus-threads.exp.
While there is clearly a problem/bug with this test on F34 and
Rawhide, it's also the case that testing should not hang. This commit
prevents the hang by waiting with the "-nowait" flag in
close_gdbserver.
The -nowait flag is also used in the kill_wait_spawned_process proc in
gdb/testsuite/lib/gdb.exp, so there is precedent for doing this.
There are also 15 other uses of "wait -i" scattered throughout the
test suite. While it's tempting to change these to also use the
-nowait flag, I think it might be safer to defer doing so until we
actually see a problem.
I've tested this patch on Fedora 32, 33, 34, and Rawhide. Results are
comparable on Fedora 32 and 33. On Fedora 34 and Rawhide, with this
commit in place, testing completes when the target_board is
native-extended-gdbserver. On those OSes, when not using this commit,
testing usually hangs due to a problem with
gdb.threads/fork-plus-threads.exp. I've also tested on all of the
mentioned OSes with target_board=native-gdbserver; for that testing,
I achieved comparable results over a number of runs. (Unfortunately
results are rarely identical due to racy tests.)
gdb/testsuite/ChangeLog:
* lib/gdbserver-support.exp (gdbserver_exit): Use the
"-nowait" flag when waiting for gdbserver to exit.
A WIP patch series broke the use case of doing "run" or "attach" while
the program is running, but it wasn't caught by the testsuite, which
means it's not covered. Add a test for that.
gdb/testsuite/ChangeLog:
* gdb.base/run-attach-while-running.exp: New.
* gdb.base/run-attach-while-running.c: New.
Change-Id: I77f098ec0b28dc2d4575ea80e941f6a75273e431
This commit:
commit d1cab9876d
Date: Tue Sep 15 11:08:56 2020 -0600
Don't use gdb_py_long_from_ulongest
Introduced a regression when GDB is compiled with Python 2. The frame
filter API expects the gdb.FrameDecorator.function () method to return
either a string (the name of a function) or an address, which GDB then
uses to lookup a msymbol.
If the address returned from gdb.FrameDecorator.function () comes from
gdb.Frame.pc () then before the above commit we would always expect to
see a PyLong object.
After the above commit we might (on Python 2) get a PyInt object.
The GDB code does not expect to see a PyInt, and only checks for a
PyLong, we then see an error message like:
RuntimeError: FrameDecorator.function: expecting a String, integer or None.
This commit just adds an additional call to PyInt_Check which handle
the missing case.
I had already written a test case to cover this issue before spotting
that the gdb.python/py-framefilter.exp test also triggers this
failure. As the new test case is slightly different I have kept it
in.
The new test forces the behaviour of gdb.FrameDecorator.function
returning an address. The reason the existing test case hits this is
due to the behaviour of the builtin gdb.FrameDecorator base class. If
the base class behaviour ever changed then the return an address case
would only be tested by the new test case.
gdb/ChangeLog:
* python/py-framefilter.c (py_print_frame): Use PyInt_Check as
well as PyLong_Check for Python 2.
gdb/testsuite/ChangeLog:
* gdb.python/py-framefilter-addr.c: New file.
* gdb.python/py-framefilter-addr.exp: New file.
* gdb.python/py-framefilter-addr.py: New file.
Resolve all of the duplicate test names in the gdb.threads/*.exp set
of tests (that I see). Nothing very exciting here, mostly either
giving tests explicit testnames, or adding with_test_prefix.
The only interesting one is gdb.threads/execl.exp, I believe the
duplicate test name was caused by an actual duplicate test. I've
remove the simpler form of the test. I don't believe we've lost any
test coverage with this change.
gdb/testsuite/ChangeLog:
* gdb.threads/execl.exp: Remove duplicate 'info threads' test.
Make use of $gdb_test_name instead of creating a separate $test
variable.
* gdb.threads/print-threads.exp: Add a with_test_prefix instead of
adding a '($name)' at the end of each test. This also catches the
one place where '($name)' was missing, and so caused a duplicate
test name.
* gdb.threads/queue-signal.exp: Give tests unique names to avoid
duplicate test names based on the command being tested.
* gdb.threads/signal-command-multiple-signals-pending.exp:
Likewise.
* lib/gdb.exp (gdb_compile_shlib_pthreads): Tweak test name to
avoid duplicate testnames when a test script uses this proc and
also gdb_compile_pthreads.
* lib/prelink-support.exp (build_executable_own_libs): Use
with_test_prefix to avoid duplicate test names when we call
build_executable twice.
My previous Ada patches introduced a bug that I found after checkin.
I had incorrectly implemented unary +. There was a test for the
overloaded case, but no test for the ordinary case.
This patch adds the tests and fixes the bug.
Tested on x86-64 Fedora 32.
gdb/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* ada-exp.y (simple_exp): Always push a result for unary '+'.
gdb/testsuite/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/fixed_points.exp: Add tests of unary + and -.
Internal testing revealed yet another Ada regression from the
expression rewrite. In this case, indirection did not use the Ada
varsize limit. The old code relied on the expression resolution
process to evaluate this subexpression with EVAL_AVOID_SIDE_EFFECTS in
order to get this error. However, this isn't always done in the new
approach; so this patch introduces another call to
ada_ensure_varsize_limit in the appropriate spot.
As with the earlier patches, this path was not tested in-tree, so this
patch also updates a test.
gdb/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_unop_ind_operation::evaluate): Call
ada_ensure_varsize_limit.
gdb/testsuite/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/varsize_limit.exp: Add new test.
* gdb.ada/varsize_limit/vsizelim.adb: Update.
In the expression rewrite, I neglected to carry over support for Ada
operator overloading. It turns out that there were no tests for this
in-tree.
This patch adds support for operator overloading, and adds the missing
test.
gdb/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* ada-lang.c (numeric_type_p, integer_type_p): Return true for
fixed-point.
* ada-exp.y (maybe_overload): New function.
(ada_wrap_overload): New function.
(ada_un_wrap2, ada_wrap2, ada_wrap_op): Use maybe_overload.
(exp1, simple_exp, relation, and_exp, and_then_exp, or_exp)
(or_else_exp, xor_exp, primary): Update.
gdb/testsuite/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/operator_call/twovecs.ads: New file.
* gdb.ada/operator_call/twovecs.adb: New file.
* gdb.ada/operator_call/opcall.adb: New file.
* gdb.ada/operator_call.exp: New file.
The expression rewrite missed an Ada resolution case. GDB previously
knew how to disambiguate the right hand side of an assignment, but now
it does not.
This patch fixes the problem and adds the missing test case.
gdb/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* ada-exp.y (exp1): Handle resolution of the right hand side of an
assignment.
gdb/testsuite/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/enums_overload/enums_overload_main.adb: New file.
* gdb.ada/enums_overload/enums_overload.ads: New file.
* gdb.ada/enums_overload/enums_overload.adb: New file.
* gdb.ada/enums_overload.exp: New file.
The expression rewrite caused a regression in the internal AdaCore
test suite. The bug was that I had dropped a bit of code from
aggregate assignment -- assign_aggregate used to return the container,
which I thought was redundant, but which can actually change during
the call. There was no test for this case in the tree, so I've added
one.
gdb/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_aggregate_operation::assign_aggregate): Return
container.
(ada_assign_operation::evaluate): Update.
* ada-exp.h (class ada_aggregate_operation) <assign_aggregate>:
Change return type.
gdb/testsuite/ChangeLog
2021-03-15 Tom Tromey <tromey@adacore.com>
* gdb.ada/assign_arr/target_wrapper.ads (IArray, Put, Do_Nothing):
Declare.
* gdb.ada/assign_arr/target_wrapper.adb: New file.
* gdb.ada/assign_arr/main_p324_051.adb (IValue): New variable.
Call Put.
* gdb.ada/assign_arr.exp: Update.
The current mechanism by which the Python gdb.current_objfile is
maintained does not allow for nested auto-load events. It is assumed
that once an auto-load script has finished loading then the current
objfile should be set back to NULL. In a nested situation, we should
be restoring the previous value.
We already have an RAII class to handle save/restore type behaviour,
so lets just switch to use that.
The test is a little contrived, but is simple enough, and triggers the
bug. The real use case might involve the auto-load script calling
functions (either in the just-loaded object file, or in the main
executable), which in turn trigger further auto-loads to occur.
gdb/ChangeLog:
* python/python.c (gdbpy_source_objfile_script): Use
make_scoped_restore to restore gdbpy_current_objfile.
(gdbpy_execute_objfile_script): Likewise.
gdb/testsuite/ChangeLog:
* gdb.python/py-auto-load-chaining-f1.c: New file.
* gdb.python/py-auto-load-chaining-f1.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining-f2.c: New file.
* gdb.python/py-auto-load-chaining-f2.o-gdb.py: New file.
* gdb.python/py-auto-load-chaining.c: New file.
* gdb.python/py-auto-load-chaining.exp: New file.
This commit resolves the remaining duplicate test names in the
gdb.python/ directory, there's 1 duplicate per test script. In each
case I have just extended some test names to make them more
descriptive.
gdb/testsuite/ChangeLog:
* gdb.python/py-bad-printers.exp: Extend test names to make them
unique.
* gdb.python/py-events.exp: Likewise.
* gdb.python/py-finish-breakpoint2.exp: Likewise.
* gdb.python/py-frame-inline.exp: Likewise.
* gdb.python/py-frame.exp: Likewise.
* gdb.python/py-infthread.exp: Likewise.
While squashing duplicate test names I spotted an actual duplicate
test, I suspect a copy & paste error in an earlier patch. I can see
no reason why we should need to duplicate this test, so I'm removing
one copy of it.
gdb/testsuite/ChangeLog:
* gdb.python/py-value-cc.exp: Remove a duplicate test.
While squashing duplicate test names I spotted what looked like a copy
& paste error. During this test a Python variable is created, and
then we call the type method on that variable. In one case we create
a variable and then call the type method on a variable created for a
previous test. I can see no reason why this should be what we want,
it doesn't line up with the comments in the test script, so I've
updated the test. Note, the expected result doesn't change, just the
command issued (the test relates to stripping typedefs).
gdb/testsuite/ChangeLog:
* gdb.python/lib-types.exp: Update the test to check the correct
python variable.
Add additional text to some test names to make them unique. In one
case, correct the test name (copy & paste error) to make it correctly
reflect what the test is doing.
gdb/testsuite/ChangeLog:
* gdb.python/py-explore-cc.exp: Extend test names to make them
unique.
I spotted a duplicate test name in this test script. Turns out it's
an actual duplicate test. Delete one copy of this test.
gdb/testsuite/ChangeLog:
* gdb.python/py-lookup-type.exp: Remove duplicate test.
