| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When running test-case gdb.base/solib-corrupted.exp on SLE-11, I get:
...
(gdb) PASS: gdb.base/solib-corrupted.exp: normal list
p/x _r_debug->r_map->l_next = _r_debug->r_map^M
'_r_debug' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/solib-corrupted.exp: make solibs looping
...
The reason that _r_debug has unknown type is that glibc debuginfo is not
installed. The test-case attempts to detect this but doesn't handle this
particular error string.
Fix this by adding the "unknown type" line to the regexp detecting missing
glibc debuginfo.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-14 Tom de Vries <tdevries@suse.de>
PR testsuite/26962
* gdb.base/solib-corrupted.exp: Handle "'_r_debug' has unknown type;
cast it to its declared type".
|
|
On SLE-11, I run into:
...
FAIL: gdb.base/batch-preserve-term-settings.exp: batch run: spawn shell \
(timeout)
...
The problem is that the shell prompt has PS1="\h:\w> ", but the test expects
a shell prompt ending in a space preceded by either '$' or '#':
...
set shell_prompt_re "\[$#\] "
...
We could easily fix this by adding '>' to shell_prompt_re, but this wouldn't
work for other PS1 setting.
Fix this instead by setting the shell prompt to "gdb-subshell$ " (as in
gdb.base/multi-line-starts-subshell.exp).
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-14 Tom de Vries <tdevries@suse.de>
PR testsuite/26951
* gdb.base/batch-preserve-term-settings.exp: Use "gdb-subshell$ " as
shell prompt.
|
|
GNAT can generate a mangled name with "B_N" (where N is a number) in
the middle, like "hello__B_1__fourth.0". This is used for names local
to a block. Multiple levels of block-local name can also occur, a
possibility that was neglected by v1 of this patch. This patch
changes gdb to handle these names.
The wild name matcher is updated a straightforward way. The full
matcher is rewritten. The hash function is updated to ensure that
this works.
This version does not seem to have the performance problems that
affected v1. In particular, the previously-slow "bt" problem has been
fixed.
gdb/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* dictionary.c (language_defn::search_name_hash): Ignore "B".
* ada-lang.c (advance_wild_match): Ignore "B".
(full_match): Remove.
(do_full_match): Rewrite.
gdb/testsuite/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* gdb.ada/nested.exp: Add new tests.
* gdb.ada/nested/hello.adb (Fourth, Fifth): New procedures.
|
|
To handle thick pointers with -fgnat-encodings=minimal, gdb will
rewrite the underlying array type to remove the bounds. However, if
the same DWARF type is used both for a thick pointer and for an
ordinary array, this will have the side effect of removing the bounds
from the array. This breaks the printing of objects of this type.
This patch fixes the problem by copying the array type, its range, and
its bounds.
gdb/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (rewrite_array_type): New function.
(quirk_ada_thick_pointer_struct): Use rewrite_array_type.
gdb/testsuite/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/ada-thick-pointer.exp: New file.
|
|
fixed_point_binop did not account for division by zero. This would
lead to gdb getting SIGFPE and subsequently cause some test cases to
hang.
gdb/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* valarith.c (fixed_point_binop): Call error on division by zero.
gdb/testsuite/ChangeLog
2020-12-14 Tom Tromey <tromey@adacore.com>
* gdb.dwarf2/dw2-fixed-point.exp: Add test for division by zero.
|
|
When running test-case gdb.base/endianity.exp using gcc-4.8, we get:
...
(gdb) x/x &o.v^M
0x7fffffffd120: 0x00000004^M
(gdb) XFAIL: gdb.base/endianity.exp: x/x &o.v
x/xh &o.w^M
0x7fffffffd124: 0x0003^M
(gdb) FAIL: gdb.base/endianity.exp: x/xh &o.w
...
The gcc 4.8 compiler does not support the scalar_storage_order attribute, so
the testcase is compiled without that attribute, and the expected results are
different.
Fix this by rather than xfailing, skipping the tests if the compiler does not
support the scalar_storage_order attribute.
Tested on x86_64-linux, with gcc-4.8, gcc-7, and clang-10.
gdb/testsuite/ChangeLog:
2020-12-13 Tom de Vries <tdevries@suse.de>
PR testsuite/26953
* gdb.base/endianity.exp: Skip tests requiring scalar_storage_order
attribute support if compiler doesn't support it.
|
|
The single test-case in the testsuite that creates an ada shared library is
gdb.ada/catch_ex_std.exp.
The test-case does use gdb_compile_shlib, but with a few tweaks that make sure
things are properly handled for ada.
Move the ada-specific code to gdb_compile_shlib, such that gdb_compile_sh can
be used for ada shared libs without tweaks.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-13 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_compile_shlib): Handle ada.
* gdb.ada/catch_ex_std.exp: Use gdb_compile_shlib to compile from
source to shared lib. Add ada to options.
|
|
There's a single test-case in the testsuite that explicitly calls gnatbind and
gnatlink: gdb.ada/catch_ex_std.exp.
Instead, use gnatmake and pass specific gnatbind and gnatlink options using
gnatmake passthrough options -bargs and -largs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-13 Tom de Vries <tdevries@suse.de>
* gdb.ada/catch_ex_std.exp: Use gnatmake -bargs and -largs instead of
calling gnatbind and gnatlink.
|
|
Add a new command to flush the dcache.
gdb/ChangeLog:
* NEWS: Mention new commands.
* target-dcache.c: Add 'cli/cli-cmds.h' include.
(maint_flush_dcache_command): New function.
(_initialize_target_dcache): Create new 'maint flush dcache'
command.
gdb/doc/ChangeLog:
* gdb.texinfo (Caching Target Data): Document 'maint flush
dcache'.
gdb/testsuite/ChangeLog:
* gdb.base/dcache-flush.c: New file.
* gdb.base/dcache-flush.exp: New file.
|
|
We currently have two flushing commands 'flushregs' and 'maint
flush-symbol-cache'. I'm planning to add at least one more so I
thought it might be nice if we bundled these together into one place.
And so I created the 'maint flush ' command prefix. Currently there
are two commands:
(gdb) maint flush symbol-cache
(gdb) maint flush register-cache
Unfortunately, even though both of the existing flush commands are
maintenance commands, I don't know how keen we about deleting existing
commands for fear of breaking things in the wild. So, both of the
existing flush commands 'maint flush-symbol-cache' and 'flushregs' are
still around as deprecated aliases to the new commands.
I've updated the testsuite to use the new command syntax, and updated
the documentation too.
gdb/ChangeLog:
* NEWS: Mention new commands, and that the old commands are now
deprecated.
* cli/cli-cmds.c (maintenanceflushlist): Define.
* cli/cli-cmds.h (maintenanceflushlist): Declare.
* maint.c (_initialize_maint_cmds): Initialise
maintenanceflushlist.
* regcache.c: Add 'cli/cli-cmds.h' include.
(reg_flush_command): Add header comment.
(_initialize_regcache): Create new 'maint flush register-cache'
command, make 'flushregs' an alias.
* symtab.c: Add 'cli/cli-cmds.h' include.
(_initialize_symtab): Create new 'maint flush symbol-cache'
command, make old command an alias.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document 'maint flush symbol-cache'.
(Maintenance Commands): Document 'maint flush register-cache'.
gdb/testsuite/ChangeLog:
* gdb.base/c-linkage-name.exp: Update to use new 'maint flush ...'
commands.
* gdb.base/killed-outside.exp: Likewise.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.perf/gmonster-null-lookup.py: Likewise.
* gdb.perf/gmonster-print-cerr.py: Likewise.
* gdb.perf/gmonster-ptype-string.py: Likewise.
* gdb.python/py-unwind.exp: Likewise.
|
|
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy', is deprecated.
No alternative known.
With the 'set' prefixes added and a comma before the final 'is
deprecated'. That is what this patch does. The expected results are
updated as needed.
gdb/ChangeLog:
* cli/cli-decode.c (deprecated_cmd_warning): Ignore the prefix
result from lookup_cmd_composition_1, use the prefixes from both
the command and the alias instead.
(lookup_cmd_composition_1): Initial prefix command is the based on
the search list being passed in. Simplify the logic for tracking
the prefix command. Replace a use of alloca with a local
std::string.
gdb/testsuite/ChangeLog:
* gdb.base/commands.exp: Update expected results.
|
|
I noticed that deprecated aliases that have a prefix don't give a
deprecated command warning. For example looking in mi/mi-main.c we
see this:
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &setlist);
deprecate_cmd (c, "set mi-async");
c = add_alias_cmd ("target-async", "mi-async", class_run, 0, &showlist);
deprecate_cmd (c, "show mi-async");
So both 'set target-async' and 'show target-async' are deprecated and
should be giving a warning, however, in use we see no warning given.
This is a consequence of how the code that should give this
warning (deprecated_cmd_warning) performs a second command lookup in
order to distinguish between aliases and real commands, and that the
code that calls this (lookup_cmd_1) strips off prefix commands as it
calls itself recursively.
As a result when we are considering an alias like 'set target-async'
we first enter lookup_cmd_1 with text = "set target-async", we spot
the 'set' command prefix and then recursively call lookup_cmd_1 with
text = "target-async".
We spot that 'target-async' is a known alias but that it is
deprecated, and so call deprecated_cmd_warning passing in the value of
text, which remember is now "target-async".
In deprecated_cmd_warning we again perform a command lookup starting
from the top-level cmdlist, but now we're trying to find just
"target-async", this fails (as this command requires the 'set' prefix,
and so no warning is given.
I resolved this issue by passing a command list to the function
deprecated_cmd_warning, this is the list in which the command can be
found.
A new test is added to cover this case.
However, there is an additional problem which will be addressed in a
subsequent patch.
Consider this GDB session:
(gdb) define set xxx_yyy
Type commands for definition of "set xxx_yyy".
End with a line saying just "end".
>echo in set xxx_yyy command\n
>end
(gdb) alias set qqq_aaa=set xxx_yyy
(gdb) maintenance deprecate set qqq_aaa
(gdb) set qqq_aaa
Warning: 'qqq_aaa', an alias for the command 'xxx_yyy' is deprecated.
No alternative known.
in set xxx_yyy command
(gdb)
Notice the warning mentions 'qqq_aaa' and 'xxx_yyy', I consider this
to be wrong. I think the proper warning should read:
(gdb) set qqq_aaa
Warning: 'set qqq_aaa', an alias for the command 'set xxx_yyy' is deprecated.
No alternative known.
With the 'set' prefixes added. A later patch will resolve this
issue.
gdb/ChangeLog:
PR cli/15104
* cli/cli-decode.c (lookup_cmd_1): Pass command list to
deprecated_cmd_warning.
(deprecated_cmd_warning): Take extra parameter, call
lookup_cmd_composition_1 and pass new parameter through.
(lookup_cmd_composition_1): New function, takes implementation of
lookup_cmd_composition but with extra parameter.
(lookup_cmd_composition): Now calls lookup_cmd_composition_1
passing in cmdlist.
* command.h (deprecated_cmd_warning): Add extra parameter to
declaration.
* top.c (execute_command): Pass cmdlist to deprecated_cmd_warning.
gdb/testsuite/ChangeLog:
PR cli/15104
* gdb.base/commands.exp: Add additional tests.
* gdb.base/completion.exp: Add additional tests.
|
|
Consider this gdb session, where on line #3 tab completion is used:
(gdb) alias xxx_yyy_zzz=break
(gdb) maint deprecate xxx_yyy_zzz
(gdb) xxx_yyy_<TAB>
The third line then updates to look like this:
(gdb) xxx_yyy_Warning: 'xxx_yyy_zzz', an alias for the command 'break' is deprecated.
No alternative known.
zzz
What's happened is during tab completion the alias has been resolved
to the actual command being aliased, and at this stage the warning is
issued. Clearly this is not what we want during tab completion.
In this commit I add a new parameter to the lookup function, a boolean
that indicates if the lookup is being done as part of completion.
This flag is used to suppress the warning. Now we get the expected
behaviour, the alias completes without any warning, but the warning is
still given once the user executes the alias.
gdb/ChangeLog:
* cli/cli-decode.c (lookup_cmd_1): Move header comment into
command.h, add extra parameter, and use this to guard giving a
warning.
* command.h (lookup_cmd_1): Add comment from cli/cli-decode.c,
include argument names in declaration, add new argument.
* completer.c (complete_line_internal_1): Remove unneeded
brackets, pass extra argument to lookup_cmd_1.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add additional tests.
|
|
When running test-case gdb.arch/i386-mpx-call.exp with target board unix/-m32,
we run into:
...
(gdb) continue^M
Continuing.^M
(gdb) FAIL: gdb.arch/i386-mpx-call.exp: upper_bnd0: continue to a bnd violation
...
Let's look first for reference at -m64, where the test passes.
The test-case uses -mmpx -fcheck-pointer-bounds to generate pointer checks in
the exec. Effectively, -fcheck-pointer-bounds modifies the calling ABI: a
call passes pointer bounds as well as arguments. The call to upper (with
four pointer arguments and an int argument, passed in 5 registers) is modified
like this:
...
lea -0xa0(%rbp),%rcx
lea -0x80(%rbp),%rdx
lea -0x60(%rbp),%rsi
lea -0x40(%rbp),%rax
mov $0x0,%r8d
+ bndmov -0x110(%rbp),%bnd3
+ bndmov -0x100(%rbp),%bnd2
+ bndmov -0xf0(%rbp),%bnd1
+ bndmov -0xe0(%rbp),%bnd0
mov %rax,%rdi
- callq <upper>
+ bnd callq <upper>
...
passsing the four pointer bounds in bounds registers BND0-3.
The top-level mechanism of the test is as follows:
- run the exec to after all mallocs are done, such that all pointer variables
are valid
- do inferior calls, similar to those present in the program
The inferior call mechanism doesn't differentiate between a call to a function
compiled with -fcheck-pointer-bounds, and one without. It merely resets the
bound registers to all-allowed state (see amd64_push_dummy_call), to make sure
the checks don't trigger during the inferior call. [ This is the same as what
happens when executing a call without bnd prefix when the BNDPRESERVE bit of
the BNDCFG register is set to 0, a provision for calling an instrumented
function using a non-instrumented call. ]
First, two inferior calls are done (default_run and verify_default_values)
with the bound registers unmodified by the test. So, the memory accesses are
performed with the bounds registers set by amd64_push_dummy_call to
all-allowed, and the bounds checks do not trigger.
Then we try to do an inferior call with modified bounds registers, set to
none-allowed. In order to do that, we set a breakpoint at *upper before
doing the inferior call. Once we hit the breakpoint during the inferior call,
the bounds registers are set to none-allowed, and we continue expecting to run
into an triggered bounds check, which takes the shape of a sigsegv.
Back to -m32. Here, the pointer arguments are passed in memory rather than
registers, so with -fcheck-pointer-bounds, the pointer bounds are placed in
the Bounds Table using bndstx:
...
movl $0x0,0x10(%eax)
lea -0x70(%ebp),%edx
mov %edx,0xc(%eax)
lea -0x5c(%ebp),%edx
mov %edx,0x8(%eax)
lea -0x48(%ebp),%edx
mov %edx,0x4(%eax)
lea -0x34(%ebp),%edx
mov %edx,(%eax)
lea 0xc(%eax),%edx
mov 0xc(%eax),%ecx
bndmov -0xa8(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
lea 0x8(%eax),%edx
mov 0x8(%eax),%ecx
bndmov -0xa0(%ebp),%bnd3
bndstx %bnd3,(%edx,%ecx,1)
lea 0x4(%eax),%edx
mov 0x4(%eax),%ecx
bndmov -0x98(%ebp),%bnd1
bndstx %bnd1,(%edx,%ecx,1)
mov (%eax),%edx
bndmov -0x90(%ebp),%bnd3
bndstx %bnd3,(%eax,%edx,1)
bnd call 804893f <upper>
...
Again, the bounds registers are reset at the start of the inferior call by
amd64_push_dummy_call, and modified by the test-case, but neither has any
effect. The code in upper reads the pointer bounds from the Bounds Table, not
from the bounds registers.
Note that for a test.c with an out-of-bounds access:
...
$ cat test.c
void foo (int *a) { volatile int v = a[1]; }
int main (void) { int a; foo (&a); return 0; }
$ gcc test.c -mmpx -fcheck-pointer-bounds -g -m32
$ ./a.out
Saw a #BR! status 1 at 0x804848d
...
and inferior call foo (&a) right before "bnd call foo" (at the point that the
bounds for a are setup in the bounds table) doesn't trigger a bounds violation:
...
(gdb) call foo (&a)
(gdb)
...
This is because the bounds table doesn't associate a pointer with bounds, but
rather a pair of pointer and pointer location. So, the bound is setup for &a,
with as location the pushed argument in the frame. The inferior call however
executes in a dummy frame, so the bound is checked for &a with as location the
pushed argument in the dummy frame, which is different, so the bounds check
doesn't trigger.
In conclusion, this is expected behaviour.
Update the test-case to not expect to override effective pointer bounds using
the bounds registers when the bounds passing is done via the Bounds Table.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26991
* gdb.arch/i386-mpx-call.exp: Don't expect to trigger bounds
violations by setting bounds registers if the bounds are passed in the
Bounds Table.
|
|
When configuring gdb using --with-mpfr=no and running test-case
gdb.base/float128.exp, we run into:
...
FAIL: gdb.base/float128.exp: print large128 (GDB may be missing MPFR support!)
...
Fix this by detecting that gdb was build without mpfr using the show
configuration command, and changing the FAIL into UNSUPPORTED.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-11 Tom de Vries <tdevries@suse.de>
PR testsuite/26954
* gdb.base/float128.exp: Detect and handle no mpfr support.
|
|
That test fails intermittently for me. The problem is a race condition
between the exec syscall and GDB resuming threads.
The initial situation is that we have two threads, let's call them
"leader" and "other". Leader is the one who is going to do the exec.
We stop at the breakpoint on the all_started function, so both threads
are stopped. When resuming, GDB resumes leader first and other second.
However, between resuming the two threads, leader has time to run and do
its exec, making other disappear. When GDB tries to resume other, it is
ino longer there. We get some "Couldn't get registers: No such
process." messages, and the state is a bit messed up.
The issue can be triggered consistently by adding a small delay after
the resume syscall:
diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
index d5a062163c7..9540339a9da 100644
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -308,6 +308,8 @@ inf_ptrace_target::resume (ptid_t ptid, int step, enum gdb_signal signal)
gdb_ptrace (request, ptid, (PTRACE_TYPE_ARG3)1, gdb_signal_to_host (signal));
if (errno != 0)
perror_with_name (("ptrace"));
+ for (int i = 0 ; i < 100; i++)
+ usleep (10000);
}
/* Wait for the child specified by PTID to do something. Return the
This patch is about fixing the test to avoid this, since the test is not
about testing this particular corner case. Handling of multi-threaded
program doing execs should be improved too, but that's not the goal of
this patch.
Fix it by adding a synchronization point in the test to make sure both
threads were resumed by GDB before doing the exec. I added two
pthread_barrier_wait calls in each thread (for a total of three). I
think adding one call in each thread would not be enough, because this
could happen:
- both threads reach the first barrier
- the "other" thread is scheduled so has time to run and hit the second
barrier
- the "leader" thread hits the all_started function breakpoint, causing
both threads to be stopped by GDB
- GDB resumes the "leader" thread
- Since the "other" thread has already reached the second barrier, the
"leader" thread is free to run past its second barrier and do the
exec, while GDB still hasn't resumed the second one
By adding two barrier calls in each thread, I think we are good. The test
passes consistently for me, even with the artificial delay added.
gdb/testsuite/ChangeLog:
PR gdb/24694
* gdb.multi/multi-arch-exec.c (thread_start, main): Add barrier
calls.
Change-Id: I25c8ea9724010b6bf20b42691c716235537d0e27
|
|
In commit 4d91ddd342 "[gdb/testsuite] Fix unbalanced braces in
gdb.tui/new-layout.exp", I tried to fix a problem with test-case
gdb.tui/new-layout.exp when running with tcl 8.5.
However, at that point I only had access to the log containing the failure,
and unfortunately my patch turned out not to be effective.
So, finally fix this problem by guarding the problematic code with:
...
if { [tcl_version_at_least 8 6] } { ... }
...
Tested on x86_64-linux, specifically SLE-11 where I ran into the failure.
gdb/testsuite/ChangeLog:
2020-12-10 Tom de Vries <tdevries@suse.de>
PR testsuite/26947
* gdb.tui/new-layout.exp: Don't execute tests with unbalanced curly
braces for tcl 8.5 and earlier.
|
|
Since commit 7c6f27129631 ("gdb: make get_discrete_bounds check for
non-constant range bounds"), subscripting flexible array member fails:
struct no_size
{
int n;
int items[];
};
(gdb) p *ns
$1 = {n = 3, items = 0x5555555592a4}
(gdb) p ns->items[0]
Cannot access memory at address 0xfffe555b733a0164
(gdb) p *((int *) 0x5555555592a4)
$2 = 101 <--- we would expect that
(gdb) p &ns->items[0]
$3 = (int *) 0xfffe5559ee829a24 <--- wrong address
Since the flexible array member (items) has an unspecified size, the array type
created for it in the DWARF doesn't have dimensions (this is with gcc 9.3.0,
Ubuntu 20.04):
0x000000a4: DW_TAG_array_type
DW_AT_type [DW_FORM_ref4] (0x00000038 "int")
DW_AT_sibling [DW_FORM_ref4] (0x000000b3)
0x000000ad: DW_TAG_subrange_type
DW_AT_type [DW_FORM_ref4] (0x00000031 "long unsigned int")
This causes GDB to create a range type (TYPE_CODE_RANGE) with a defined
constant low bound (dynamic_prop with kind PROP_CONST) and an undefined
high bound (dynamic_prop with kind PROP_UNDEFINED).
value_subscript gets both bounds of that range using
get_discrete_bounds. Before commit 7c6f27129631, get_discrete_bounds
didn't check the kind of the dynamic_props and would just blindly read
them as if they were PROP_CONST. It would return 0 for the high bound,
because we zero-initialize the range_bounds structure. And it didn't
really matter in this case, because the returned high bound wasn't used
in the end.
Commit 7c6f27129631 changed get_discrete_bounds to return a failure if
either the low or high bound is not a constant, to make sure we don't
read a dynamic prop that isn't a PROP_CONST as a PROP_CONST. This
change made get_discrete_bounds start to return a failure for that
range, and as a result would not set *lowp and *highp. And since
value_subscript doesn't check get_discrete_bounds' return value, it just
carries on an uses an uninitialized value for the low bound. If
value_subscript did check the return value of get_discrete_bounds, we
would get an error message instead of a bogus value. But it would still
be a bug, as we wouldn't be able to print the flexible array member's
elements.
Looking at value_subscript, we see that the low bound is always needed,
but the high bound is only needed if !c_style. So, change
value_subscript to use get_discrete_low_bound and
get_discrete_high_bound separately. This fixes the case described
above, where the low bound is known but the high bound isn't (and is not
needed). This restores the original behavior without accessing a
dynamic_prop in a wrong way.
A test is added. In addition to the case described above, a case with
an array member of size 0 is added, which is a GNU C extension that
existed before flexible array members were introduced. That case
currently fails when compiled with gcc <= 8. gcc <= 8 produces DWARF
similar to the one shown above, while gcc 9 adds a DW_AT_count of 0 in
there, which makes the high bound known. A case where an array member
of size 0 is the only member of the struct is also added, as that was
how PR 28675 was originally reported, and it's an interesting corner
case that I think could trigger other funny bugs.
Question about the implementation: in value_subscript, I made it such
that if the low or high bound is unknown, we fall back to zero. That
effectively makes it the same as it was before 7c6f27129631. But should
we instead error() out?
gdb/ChangeLog:
PR 26875, PR 26901
* gdbtypes.c (get_discrete_low_bound): Make non-static.
(get_discrete_high_bound): Make non-static.
* gdbtypes.h (get_discrete_low_bound): New declaration.
(get_discrete_high_bound): New declaration.
* valarith.c (value_subscript): Only fetch high bound if
necessary.
gdb/testsuite/ChangeLog:
PR 26875, PR 26901
* gdb.base/flexible-array-member.c: New test.
* gdb.base/flexible-array-member.exp: New test.
Change-Id: I832056f80e6c56f621f398b4780d55a3a1e299d7
|
|
Redo fix committed in commit 67748e0f66 "[gdb/testsuite] Make
gdb.arch/amd64-gs_base.exp unsupported for i386" using is_amd64_regs_target.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-08 Tom de Vries <tdevries@suse.de>
* gdb.arch/amd64-gs_base.exp: Undo commit 67748e0f66, reimplement
using is_amd64_regs_target.
|
|
When running test-case gdb.ada/mi_task_arg.exp with target board unix/-m32, I
run into:
...
(gdb) ^M
Expecting: ^(-stack-list-arguments 1[^M
]+)?(\^done,stack-args=\[ \
frame={level="0",args=\[\]}, \
frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}\]}, \
frame={level="2",args=\[({name="self_id",value="0x[0-9A-Fa-f]+"})?\]},.*[^M
]+[(]gdb[)] ^M
[ ]*)
-stack-list-arguments 1^M
^done,stack-args=[ \
frame={level="0",args=[]}, \
frame={level="1",args=[{name="<_task>",value="0x808abf0"}]}, \
frame={level="2",args=[{name="self_id",value="<optimized out>"}]}, \
frame={level="3",args=[]},frame={level="4",args=[]}]^M
(gdb) ^M
FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output)
...
The problem is that we're expecting a $hex for the value of self_id, but
instead get <optimized out>.
Looking at the debug info for self_id:
...
<1><12a1f>: Abbrev Number: 84 (DW_TAG_subprogram)
<12a20> DW_AT_name : system__tasking__stages__task_wrapper
...
<2><12a35>: Abbrev Number: 61 (DW_TAG_formal_parameter)
<12a36> DW_AT_name : self_id
<12a40> DW_AT_location : 0x459e (location list)
...
it refers to location information here:
...
0000459e 08053060 080531ac (DW_OP_fbreg: 0)
000045aa 0805327c 080532a5 (DW_OP_fbreg: 0)
000045b6 08053320 08053324 (DW_OP_fbreg: 0)
...
while the pc used to retrieve the location information is 0x080531c5:
...
$ gdb -batch outputs/gdb.ada/mi_task_arg/task_switch \
-ex "break 57" -ex run -ex bt
...
#0 task_switch.break_me () at task_switch.adb:57
#1 0x0804aaae in task_switch.caller (<_task>=0x808abf0) \
at task_switch.adb:51
#2 0x080531c5 in system.tasking.stages.task_wrapper \
(self_id=<optimized out>) at s-tassta.adb:1295
...
which indeed falls outside of the ranges listed in the location info.
Fix this by accepting <optimized out> as valid value of self_id.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-08 Tom de Vries <tdevries@suse.de>
* gdb.ada/mi_task_arg.exp: Accept <optimized out> as valid value of
self_id.
|
|
Commit:
commit 4d142eaa28c64565b58fcdb5a83377ec9b778cb1
Author: Jan Kratochvil <jan.kratochvil@redhat.com>
AuthorDate: Tue Jul 2 20:06:12 2013 +0000
gdb/testsuite/
* gdb.base/break-on-linker-gcd-function.exp: Replace
prepare_for_testing by build_executable_from_specs and clean_restart.
...
did:
set additional_flags {-ffunction-sections -Wl,--gc-sections}
-if {[prepare_for_testing $testfile.exp $testfile $srcfile \
- [list debug c++ additional_flags=$additional_flags]]} {
+if {[build_executable_from_specs $testfile.exp $testfile \
+ {c++ additional_flags=-Wl,--gc-sections} \
+ $srcfile {debug c++ additional_flags=-ffunction-sections}]} {
and that left the additional_flags variable behind. Remove it.
gdb/testsuite/ChangeLog:
* gdb.base/break-on-linker-gcd-function.exp: Remove unused
'additional_flags' variable.
|
|
The commit
commit 733d554a4625db4ffb89b7a20e1cf27ab071ef4d
Author: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Date: Tue Oct 27 10:56:03 2020 +0100
gdb/breakpoint: add flags to 'condition' and 'break' commands to force condition
introduced the '-force-condition' flag to the 'break' command. This
flag was defined as a keyword like 'thread', 'task', and 'if'.
However, it starts with '-'. This difference caused an uncovered case
when tab-completing a seemingly complete linespec.
Below, we see "-force-condition" in the completion list, where both
the options and the keywords are listed:
(gdb) break -function main <TAB>
-force-condition -function -label -line -qualified
-source if task thread
But tab-completing '-' lists only options:
(gdb) break -function main -<TAB>
-function -label -line -qualified -source
This patch fixes the problem by adding keywords to the completion
list, so that we see:
(gdb) break -function main -<TAB>
-force-condition -function -label -line -qualified -source
gdb/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* completer.c (complete_explicit_location): Also add keywords
that start with '-' to the completion list.
gdb/testsuite/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.linespec/explicit.exp: Extend with a test to check completing
'-' after seemingly complete options.
|
|
The break command's "-force-condition" flag is currently required to
be followed by the "if" keyword. This prevents flexibility when using
other keywords, e.g. "thread":
(gdb) break main -force-condition thread 1 if foo
Function "main -force-condition" not defined.
Make breakpoint pending on future shared library load? (y or [n]) n
Remove the requirement that "-force-condition" is always followed by
an "if", so that more flexibility is obtained when positioning
keywords.
gdb/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* linespec.c (linespec_lexer_lex_keyword): The "-force-condition"
keyword may be followed by any keyword.
* breakpoint.c (find_condition_and_thread): Advance 'tok' by
'toklen' in the case for "-force-condition".
gdb/testsuite/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.linespec/keywords.exp: Add tests to check positional
flexibility of "-force-condition".
|
|
Suppose we have the script file below:
break main
commands
print 123
end
run
If started with this script file, GDB executes the breakpoint command:
$ gdb -q -x myscript --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Breakpoint 1, main () at test.c:2
2 return 0;
$1 = 123
(gdb)
However, if we remove the "run" line from the script and pass it with
the '-ex' option instead, the command is not executed:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb)
If the user enters a command at this point, the breakpoint command
is executed, yielding weird output:
$ gdb -q -x myscript_no_run --args ./test
Reading symbols from ./test...
Breakpoint 1 at 0x114e: file test.c, line 2.
Starting program: /path/to/test
Breakpoint 1, main () at test.c:2
2 return 0;
(gdb) print "a"
$1 = "a"
$2 = 123
When consuming script files, GDB runs bp actions after executing a
command. See `command_handler` in event-top.c:
if (c[0] != '#')
{
execute_command (command, ui->instream == ui->stdin_stream);
/* Do any commands attached to breakpoint we stopped at. */
bpstat_do_actions ();
}
However, for '-ex' commands, `bpstat_do_actions` is not invoked.
Hence, the misaligned output explained above occurs. To fix the
problem, add a call to `bpstat_do_actions` after executing a command.
gdb/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* main.c (catch_command_errors): Add a flag parameter; invoke
`bpstat_do_actions` if the flag is set.
(execute_cmdargs): Update a call to `catch_command_errors`.
gdb/testsuite/ChangeLog:
2020-12-07 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/bp-cmds-run-with-ex.c: New file.
* gdb.base/bp-cmds-run-with-ex.exp: New file.
* gdb.base/bp-cmds-run-with-ex.gdb: New file.
* gdb.gdb/python-interrupts.exp: Update the call to
'catch_command_errors' with the new argument.
* gdb.gdb/python-selftest.exp: Ditto.
|
|
displaced steps
Today, GDB only allows a single displaced stepping operation to happen
per inferior at a time. There is a single displaced stepping buffer per
inferior, whose address is fixed (obtained with
gdbarch_displaced_step_location), managed by infrun.c.
In the case of the AMD ROCm target [1] (in the context of which this
work has been done), it is typical to have thousands of threads (or
waves, in SMT terminology) executing the same code, hitting the same
breakpoint (possibly conditional) and needing to to displaced step it at
the same time. The limitation of only one displaced step executing at a
any given time becomes a real bottleneck.
To fix this bottleneck, we want to make it possible for threads of a
same inferior to execute multiple displaced steps in parallel. This
patch builds the foundation for that.
In essence, this patch moves the task of preparing a displaced step and
cleaning up after to gdbarch functions. This allows using different
schemes for allocating and managing displaced stepping buffers for
different platforms. The gdbarch decides how to assign a buffer to a
thread that needs to execute a displaced step.
On the ROCm target, we are able to allocate one displaced stepping
buffer per thread, so a thread will never have to wait to execute a
displaced step.
On Linux, the entry point of the executable if used as the displaced
stepping buffer, since we assume that this code won't get used after
startup. From what I saw (I checked with a binary generated against
glibc and musl), on AMD64 we have enough space there to fit two
displaced stepping buffers. A subsequent patch makes AMD64/Linux use
two buffers.
In addition to having multiple displaced stepping buffers, there is also
the idea of sharing displaced stepping buffers between threads. Two
threads doing displaced steps for the same PC could use the same buffer
at the same time. Two threads stepping over the same instruction (same
opcode) at two different PCs may also be able to share a displaced
stepping buffer. This is an idea for future patches, but the
architecture built by this patch is made to allow this.
Now, the implementation details. The main part of this patch is moving
the responsibility of preparing and finishing a displaced step to the
gdbarch. Before this patch, preparing a displaced step is driven by the
displaced_step_prepare_throw function. It does some calls to the
gdbarch to do some low-level operations, but the high-level logic is
there. The steps are roughly:
- Ask the gdbarch for the displaced step buffer location
- Save the existing bytes in the displaced step buffer
- Ask the gdbarch to copy the instruction into the displaced step buffer
- Set the pc of the thread to the beginning of the displaced step buffer
Similarly, the "fixup" phase, executed after the instruction was
successfully single-stepped, is driven by the infrun code (function
displaced_step_finish). The steps are roughly:
- Restore the original bytes in the displaced stepping buffer
- Ask the gdbarch to fixup the instruction result (adjust the target's
registers or memory to do as if the instruction had been executed in
its original location)
The displaced_step_inferior_state::step_thread field indicates which
thread (if any) is currently using the displaced stepping buffer, so it
is used by displaced_step_prepare_throw to check if the displaced
stepping buffer is free to use or not.
This patch defers the whole task of preparing and cleaning up after a
displaced step to the gdbarch. Two new main gdbarch methods are added,
with the following semantics:
- gdbarch_displaced_step_prepare: Prepare for the given thread to
execute a displaced step of the instruction located at its current PC.
Upon return, everything should be ready for GDB to resume the thread
(with either a single step or continue, as indicated by
gdbarch_displaced_step_hw_singlestep) to make it displaced step the
instruction.
- gdbarch_displaced_step_finish: Called when the thread stopped after
having started a displaced step. Verify if the instruction was
executed, if so apply any fixup required to compensate for the fact
that the instruction was executed at a different place than its
original pc. Release any resources that were allocated for this
displaced step. Upon return, everything should be ready for GDB to
resume the thread in its "normal" code path.
The displaced_step_prepare_throw function now pretty much just offloads
to gdbarch_displaced_step_prepare and the displaced_step_finish function
offloads to gdbarch_displaced_step_finish.
The gdbarch_displaced_step_location method is now unnecessary, so is
removed. Indeed, the core of GDB doesn't know how many displaced step
buffers there are nor where they are.
To keep the existing behavior for existing architectures, the logic that
was previously implemented in infrun.c for preparing and finishing a
displaced step is moved to displaced-stepping.c, to the
displaced_step_buffer class. Architectures are modified to implement
the new gdbarch methods using this class. The behavior is not expected
to change.
The other important change (which arises from the above) is that the
core of GDB no longer prevents concurrent displaced steps. Before this
patch, start_step_over walks the global step over chain and tries to
initiate a step over (whether it is in-line or displaced). It follows
these rules:
- if an in-line step is in progress (in any inferior), don't start any
other step over
- if a displaced step is in progress for an inferior, don't start
another displaced step for that inferior
After starting a displaced step for a given inferior, it won't start
another displaced step for that inferior.
In the new code, start_step_over simply tries to initiate step overs for
all the threads in the list. But because threads may be added back to
the global list as it iterates the global list, trying to initiate step
overs, start_step_over now starts by stealing the global queue into a
local queue and iterates on the local queue. In the typical case, each
thread will either:
- have initiated a displaced step and be resumed
- have been added back by the global step over queue by
displaced_step_prepare_throw, because the gdbarch will have returned
that there aren't enough resources (i.e. buffers) to initiate a
displaced step for that thread
Lastly, if start_step_over initiates an in-line step, it stops
iterating, and moves back whatever remaining threads it had in its local
step over queue to the global step over queue.
Two other gdbarch methods are added, to handle some slightly annoying
corner cases. They feel awkwardly specific to these cases, but I don't
see any way around them:
- gdbarch_displaced_step_copy_insn_closure_by_addr: in
arm_pc_is_thumb, arm-tdep.c wants to get the closure for a given
buffer address.
- gdbarch_displaced_step_restore_all_in_ptid: when a process forks
(at least on Linux), the address space is copied. If some displaced
step buffers were in use at the time of the fork, we need to restore
the original bytes in the child's address space.
These two adjustments are also made in infrun.c:
- prepare_for_detach: there may be multiple threads doing displaced
steps when we detach, so wait until all of them are done
- handle_inferior_event: when we handle a fork event for a given
thread, it's possible that other threads are doing a displaced step at
the same time. Make sure to restore the displaced step buffer
contents in the child for them.
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/ChangeLog:
* displaced-stepping.h (struct
displaced_step_copy_insn_closure): Adjust comments.
(struct displaced_step_inferior_state) <step_thread,
step_gdbarch, step_closure, step_original, step_copy,
step_saved_copy>: Remove fields.
(struct displaced_step_thread_state): New.
(struct displaced_step_buffer): New.
* displaced-stepping.c (displaced_step_buffer::prepare): New.
(write_memory_ptid): Move from infrun.c.
(displaced_step_instruction_executed_successfully): New,
factored out of displaced_step_finish.
(displaced_step_buffer::finish): New.
(displaced_step_buffer::copy_insn_closure_by_addr): New.
(displaced_step_buffer::restore_in_ptid): New.
* gdbarch.sh (displaced_step_location): Remove.
(displaced_step_prepare, displaced_step_finish,
displaced_step_copy_insn_closure_by_addr,
displaced_step_restore_all_in_ptid): New.
* gdbarch.c: Re-generate.
* gdbarch.h: Re-generate.
* gdbthread.h (class thread_info) <displaced_step_state>: New
field.
(thread_step_over_chain_remove): New declaration.
(thread_step_over_chain_next): New declaration.
(thread_step_over_chain_length): New declaration.
* thread.c (thread_step_over_chain_remove): Make non-static.
(thread_step_over_chain_next): New.
(global_thread_step_over_chain_next): Use
thread_step_over_chain_next.
(thread_step_over_chain_length): New.
(global_thread_step_over_chain_enqueue): Add debug print.
(global_thread_step_over_chain_remove): Add debug print.
* infrun.h (get_displaced_step_copy_insn_closure_by_addr):
Remove.
* infrun.c (get_displaced_stepping_state): New.
(displaced_step_in_progress_any_inferior): Remove.
(displaced_step_in_progress_thread): Adjust.
(displaced_step_in_progress): Adjust.
(displaced_step_in_progress_any_thread): New.
(get_displaced_step_copy_insn_closure_by_addr): Remove.
(gdbarch_supports_displaced_stepping): Use
gdbarch_displaced_step_prepare_p.
(displaced_step_reset): Change parameter from inferior to
thread.
(displaced_step_prepare_throw): Implement using
gdbarch_displaced_step_prepare.
(write_memory_ptid): Move to displaced-step.c.
(displaced_step_restore): Remove.
(displaced_step_finish): Implement using
gdbarch_displaced_step_finish.
(start_step_over): Allow starting more than one displaced step.
(prepare_for_detach): Handle possibly multiple threads doing
displaced steps.
(handle_inferior_event): Handle possibility that fork event
happens while another thread displaced steps.
* linux-tdep.h (linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter.
* linux-tdep.c (struct linux_info) <disp_step_buf>: New field.
(linux_displaced_step_prepare): New.
(linux_displaced_step_finish): New.
(linux_displaced_step_copy_insn_closure_by_addr): New.
(linux_displaced_step_restore_all_in_ptid): New.
(linux_init_abi): Add supports_displaced_step parameter,
register displaced step methods if true.
(_initialize_linux_tdep): Register inferior_execd observer.
* amd64-linux-tdep.c (amd64_linux_init_abi_common): Add
supports_displaced_step parameter, adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
(amd64_linux_init_abi): Adjust call to
amd64_linux_init_abi_common.
(amd64_x32_linux_init_abi): Likewise.
* aarch64-linux-tdep.c (aarch64_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-linux-tdep.c (arm_linux_init_abi): Likewise.
* i386-linux-tdep.c (i386_linux_init_abi): Likewise.
* alpha-linux-tdep.c (alpha_linux_init_abi): Adjust call to
linux_init_abi.
* arc-linux-tdep.c (arc_linux_init_osabi): Likewise.
* bfin-linux-tdep.c (bfin_linux_init_abi): Likewise.
* cris-linux-tdep.c (cris_linux_init_abi): Likewise.
* csky-linux-tdep.c (csky_linux_init_abi): Likewise.
* frv-linux-tdep.c (frv_linux_init_abi): Likewise.
* hppa-linux-tdep.c (hppa_linux_init_abi): Likewise.
* ia64-linux-tdep.c (ia64_linux_init_abi): Likewise.
* m32r-linux-tdep.c (m32r_linux_init_abi): Likewise.
* m68k-linux-tdep.c (m68k_linux_init_abi): Likewise.
* microblaze-linux-tdep.c (microblaze_linux_init_abi): Likewise.
* mips-linux-tdep.c (mips_linux_init_abi): Likewise.
* mn10300-linux-tdep.c (am33_linux_init_osabi): Likewise.
* nios2-linux-tdep.c (nios2_linux_init_abi): Likewise.
* or1k-linux-tdep.c (or1k_linux_init_abi): Likewise.
* riscv-linux-tdep.c (riscv_linux_init_abi): Likewise.
* s390-linux-tdep.c (s390_linux_init_abi_any): Likewise.
* sh-linux-tdep.c (sh_linux_init_abi): Likewise.
* sparc-linux-tdep.c (sparc32_linux_init_abi): Likewise.
* sparc64-linux-tdep.c (sparc64_linux_init_abi): Likewise.
* tic6x-linux-tdep.c (tic6x_uclinux_init_abi): Likewise.
* tilegx-linux-tdep.c (tilegx_linux_init_abi): Likewise.
* xtensa-linux-tdep.c (xtensa_linux_init_abi): Likewise.
* ppc-linux-tdep.c (ppc_linux_init_abi): Adjust call to
linux_init_abi. Remove call to
set_gdbarch_displaced_step_location.
* arm-tdep.c (arm_pc_is_thumb): Call
gdbarch_displaced_step_copy_insn_closure_by_addr instead of
get_displaced_step_copy_insn_closure_by_addr.
* rs6000-aix-tdep.c (rs6000_aix_init_osabi): Adjust calls to
clear gdbarch methods.
* rs6000-tdep.c (struct ppc_inferior_data): New structure.
(get_ppc_per_inferior): New function.
(ppc_displaced_step_prepare): New function.
(ppc_displaced_step_finish): New function.
(ppc_displaced_step_restore_all_in_ptid): New function.
(rs6000_gdbarch_init): Register new gdbarch methods.
* s390-tdep.c (s390_gdbarch_init): Don't call
set_gdbarch_displaced_step_location, set new gdbarch methods.
gdb/testsuite/ChangeLog:
* gdb.arch/amd64-disp-step-avx.exp: Adjust pattern.
* gdb.threads/forking-threads-plus-breakpoint.exp: Likewise.
* gdb.threads/non-stop-fair-events.exp: Likewise.
Change-Id: I387cd235a442d0620ec43608fd3dc0097fcbf8c8
|
|
When a process does an exec, all its program space is replaced with the
newly loaded executable. All non-main threads disappear and the main
thread starts executing at the entry point of the new executable.
Things can go wrong if a displaced step operation is in progress while
we process the exec event.
If the main thread is the one executing the displaced step: when that
thread (now executing in the new executable) stops somewhere (say, at a
breakpoint), displaced_step_fixup will run and clear up the state. We
will execute the "fixup" phase for the instruction we single-stepped in
the old program space. We are now in a completely different context,
so doing the fixup may corrupt the state.
If it is a non-main thread that is doing the displaced step: while
handling the exec event, GDB deletes the thread_info representing that
thread (since the thread doesn't exist in the inferior after the exec).
But inferior::displaced_step_state::step_thread will still point to it.
When handling events later, this condition, in displaced_step_fixup,
will likely never be true:
/* Was this event for the thread we displaced? */
if (displaced->step_thread != event_thread)
return 0;
... since displaced->step_thread points to a deleted thread (unless that
storage gets re-used for a new thread_info, but that wouldn't be good
either). This effectively makes the displaced stepping buffer occupied
for ever. When a thread in the new program space will want to do a
displaced step, it will wait for ever.
I think we simply need to reset the displaced stepping state of the
inferior on exec. Everything execution-related that existed before the
exec is now gone.
Similarly, if a thread does an in-line step over an exec syscall
instruction, nothing clears the in-line step over info when the event is
handled. So it the in-line step over info stays there indefinitely, and
things hang because we can never start another step over. To fix this,
I added a call to clear_step_over_info in infrun_inferior_execd.
Add a test with a program with two threads that does an exec. The test
includes the following axes:
- whether it's the leader thread or the other thread that does the exec.
- whether the exec'r and exec'd program have different text segment
addresses. This is to hopefully catch cases where the displaced
stepping info doesn't get reset, and GDB later tries to restore bytes
of the old address space in the new address space. If the mapped
addresses are different, we should get some memory error. This
happens without the patch applied:
$ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true -ex "b main" -ex r -ex "b my_execve_syscall if 0" -ex "set displaced-stepping on"
...
Breakpoint 1, main (argc=1, argv=0x7fffffffde38) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.threads/step-over-exec.c:69
69 argv0 = argv[0];
Breakpoint 2 at 0x60133a: file /home/simark/src/binutils-gdb/gdb/testsuite/lib/my-syscalls.S, line 34.
(gdb) c
Continuing.
[New Thread 0x7ffff7c62640 (LWP 1455423)]
Leader going in exec.
Exec-ing /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
[Thread 0x7ffff7c62640 (LWP 1455423) exited]
process 1455418 is executing new program: /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/step-over-exec/step-over-exec-execr-thread-leader-diff-text-segs-true-execd
Error in re-setting breakpoint 2: Function "my_execve_syscall" not defined.
No unwaited-for children left.
(gdb) n
Single stepping until exit from function _start,
which has no line number information.
Cannot access memory at address 0x6010d2
(gdb)
- Whether displaced stepping is allowed or not, so that we end up
testing both displaced stepping and in-line stepping on arches that do
support displaced stepping (otherwise, it just tests in-line stepping
twice I suppose)
To be able to precisely put a breakpoint on the syscall instruction, I
added a small assembly file (lib/my-syscalls.S) that contains minimal
Linux syscall wrappers. I prefer that to the strategy used in
gdb.base/step-over-syscall.exp, which is to stepi into the glibc wrapper
until we find something that looks like a syscall instruction, I find
that more predictable.
gdb/ChangeLog:
* infrun.c (infrun_inferior_execd): New function.
(_initialize_infrun): Attach inferior_execd observer.
gdb/testsuite/ChangeLog:
* gdb.threads/step-over-exec.exp: New.
* gdb.threads/step-over-exec.c: New.
* gdb.threads/step-over-exec-execd.c: New.
* lib/my-syscalls.S: New.
* lib/my-syscalls.h: New.
Change-Id: I1bbc8538e683f53af5b980091849086f4fec5ff9
|
|
When using the single-element form of argument to declare_labels, the
generated label (in the assembly file) is of the format ".LlabelN",
where N is a number.
I propose making it use the name of the label by default. Calling:
declare_labels foo
will generate the ".LfooN" in the assembly file (again, where N is a
number). When debugging the output of the DWARF assembler, it makes it
easier to map labels to the source. Also, when defining the same label
twice by mistake in the Tcl code (like I d id), it's easier to track the
error from the message to the root cause:
-/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Llabel5' is already defined
+/home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/implptrpiece/implptrpiece-dw.S:62: Error: symbol `.Lvar_label5' is already defined
This doesn't change anything for the test cases, it just makes the
assembly output a bit nicer.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (declare_labels): Use name as text if text is
not provided.
Change-Id: I63856c1fa6390498fd5b9d66f471f817ff0a465c
|
|
With target board unix/-m32 I run into:
...
(gdb) print /x $fs_base^M
$1 = void^M
(gdb) FAIL: gdb.arch/amd64-gs_base.exp: print fs_base
...
The problem is that the fs_base register is not supported for i386.
Fix this by making the test unsupported if fs_base/gs_base don't show up in
info register sys output.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
PR testsuite/26990
* gdb.arch/amd64-gs_base.exp: Handle -m32 where fs_base and gs_base
are unsupported.
|
|
In gdb.reverse/insn-reverse.exp, we have loop containing a call to
gdb_test_multiple, which itself contains a break:
...
for {} {$count < 500} {incr count} {
...
gdb_test_multiple "x/i \$pc" "" {
...
break
}
...
On SLE-11 with:
...
$ runtest --version
Expect version is 5.44.1.11
Tcl version is 8.5
Framework version is 1.4.4
...
the break doesn't seem to have the effect of breaking out of the loop.
The break does have the effect of terminating evaluation of the expect clause,
which means we don't set insn_array, after which we run into:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
ERROR: can't read "insn_array(5)": no such element in array
...
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse.exp: Don't break inside gdb_test_multiple
clause.
|
|
Consider the test-case gdb.reverse/insn-reverse.exp.
After the loop setting count, the valid entries in various arrays range from 0
to $count - 1 inclusive.
Then $count is decremented:
...
incr count -1
...
after which the valid entries range from 0 to $count inclusive.
The first subsequent loop handles that properly:
...
for {set i $count} {$i >= 0} {incr i -1} {
...
but the following loop does not, because it treats $count as exclusive bound:
...
for {set i 0} {$i < $count} {incr i} {
...
Fix this by removing the incr, and using $count - 1 as starting value in the
first loop.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse.exp: Fix count handling.
|
|
When running test-case gdb.reverse/insn-reverse.exp with target board
unix/-m32, we get:
...
spawn -ignore SIGHUP gcc -fno-stack-protector -fdiagnostics-color=never \
-c -g -m32 -o insn-reverse0.o insn-reverse.c^M
insn-reverse-x86.c: Assembler messages:^M
insn-reverse-x86.c:88: Error: bad register name `%r8w'^M
....
Fix this by guarding x86_64 assembly in insn-reverse-x86.c with #ifdef
__x86_64__.
Tested on x86_64-linux, with native and unix/-m32.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse-x86.c: Guard x86_64 assembly with #ifdef
__x86_64__.
|
|
Consider test-case gdb.reverse/insn-reverse.exp.
It runs a number of subtests, dependent on the architecture, f.i. for
x86_64 it runs subtests rdrand and rdseed.
For each subtest, it checks whether the subtest is supported and otherwise
bails out of that subtest.
However, there may be a problem with the support test or the information it
relies on, and if it states that a subtest is supported while it is actually
not, we may run into a SIGILL, as f.i. described in PR21166, which results in
tcl errors like this:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.reverse/insn-reverse.exp.
ERROR: can't read "insn_array(5)": no such element in array
...
We can emulate this by inserting a sigfpe in function rdrand in
insn-reverse-x86.c, like this:
...
volatile int a = 0; volatile int b = 1; volatile int c = b / a;
...
The problem is that the loop in the test-case attempts to stepi over of all
insn in rdrand, but because of the signal it will never get to the last insn.
Handle this by detecting that the stepi made no progress, and bailing out of
the loop.
Furthermore, make running of the subtests independent, such that a SIGILL in
subtest rdrand does not affect running of subtest rdseed.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-04 Tom de Vries <tdevries@suse.de>
* gdb.reverse/insn-reverse.c (test_nr): New var.
(usage, parse_args): New function.
(main): Call parse_args. Only run test for test_nr.
* gdb.reverse/insn-reverse.exp: Detect lack of progress in stepi loop
and bail out. Run subtests individually, using an inferior arg
specifying the subtest.
|
|
In this commit:
commit 767a879e31ce31179e6135c2f991f670a35709fa
Date: Tue Jun 9 17:38:30 2020 +0100
gdb/riscv: Improved register alias name creation
RISC-V GDB was changed to make use of the DECLARE_CSR_ALIAS macro to
define register aliases for some CSRs. Actually, only one alias was
created 'dscratch' as an alias for 'dscratch0'. All of the other
DECLARE_CSR_ALIAS lines (from include/opcode/riscv-opc.h) were
filtered out.
In this commit:
commit 08ccfccf0ed825be9be2972594d4be4a2207ef13
Date: Mon Jun 8 10:54:53 2020 +0800
RISC-V: Support debug and float CSR as the unprivileged ones.
Changes were made to include/opcode/riscv-opc.h so that GDB no longer
created even the dscratch alias.
This caused a test failure in gdb.arch/riscv-tdesc-regs.exp.
In looking at how to address this failure I think that the best
strategy is, for now at least, to just remove the code that tries to
create aliases with DECLARE_CSR_ALIAS.
My thoughts are that:
1. At least some of the aliases are for CSRs where the register now
has a completely different use. Being able to reference the CSR
using a completely inappropriate name just seems confusing. This
was solved by the filtering added in the first commit referenced
above. But we certainly don't want to blindly add all aliases.
2. Names presented in a target description are always honoured, so
if a user has a legacy target then they should just start sending a
target description with their legacy register names in, this problem
is then solved.
3. It's easy enough to figure out which CSRs a target has with the
info registers command, so missing an alias shouldn't be a big
issue.
4. Allowing users to use names for registers that differ from the
names the target announces doesn't feel like a critical feature. If
in the future targets want multiple names for a register then maybe
we could/should extend target descriptions to allow the target to
send aliases as well as the primary name.... but that can wait for
another day.
So in this commit I remove the use of DECLARE_CSR_ALIAS, and remove
the test that was failing.
gdb/ChangeLog:
* riscv-tdep.c (riscv_create_csr_aliases): Remove use of
DECLARE_CSR_ALIAS.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp: Remove unwanted test.
|
|
Unknown riscv CSRs should not be in the 'general' group, but should be
in the system and csr register groups.
To see this in action connect to QEMU, this target advertises two
registers dscratch and mucounteren which are unknown to GDB (these are
legacy CSRs). Before this commit these registers would show up in the
output of:
(gdb) info registers
....
dscratch Could not fetch register "dscratch"; remote failure reply 'E14'
mucounteren Could not fetch register "mucounteren"; remote failure reply 'E14'
Ignore the errors, this is just a QEMU annoyance, it advertises these
CSRs, but doesn't actually let GDB read them. These registers don't
show up in the output of either:
(gdb) info registers csr
(gdb) info registers system
After this commit this situation is reveresed, which makes more sense
to me.
gdb/ChangeLog:
* riscv-tdep.c (riscv_is_unknown_csr): New function,
implementation moved from riscv_register_reggroup_p.
(riscv_register_reggroup_p): Update group handling for unknown
CSRs.
gdb/testsuite/ChangeLog:
* gdb.arch/riscv-tdesc-regs.exp (get_expected_result): New proc,
update test to use this.
|
|
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exc-1.exp: Fix indentation.
Change-Id: I02ba8a518aae9cb67106d09bef92968a7078e91e
|
|
Replace the manual with_test_prefix in the do_test proc with using
foreach_with_prefix at the top-level. This helps reduce the indentation
level of the code a bit, and makes the test names in sync with the
variable names used in the code.
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exc-1.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-2.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-3.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
* gdb.threads/non-ldr-exc-4.exp: Use foreach_with_prefix.
(do_test): Don't use with_test_prefix.
Change-Id: I3af1df2eee1a8add427a67b6048bb6dede41cbeb
|
|
Maybe there's something I don't understand in that test, but the comment
seems wrong. It checks what happens when the non-leader thread does an
exit, not the leader.
gdb/testsuite/ChangeLog:
* gdb.threads/non-ldr-exit.exp: Fix comment.
Change-Id: I35c96a70c097fa9529737874f54f3f78036008a4
|
|
Currently when printing an XML description GDB prints enum values like
this:
<enum id="levels_type" size="4">
<field name="low" start="0"/>
<field name="high" start="1"/>
</enum>
This is incorrect, and is most likely a copy and paste error with the
struct and flags printing code. The correct syntax is:
<enum id="levels_type" size="4">
<evalue name="low" value="0"/>
<evalue name="high" value="1"/>
</enum>
A test is included to cover this functionality.
gdb/testsuite/ChangeLog:
* gdb.xml/maint-xml-dump-03.xml: New file.
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit): Print enum fields using
'evalue' syntax.
|
|
Revert empty commits:
- "[gdb] Don't return non-existing path in debuginfod_source_query"
commit 59404f827cb1134b68dbf228d380ff86d15c9f01
- "[gdb/testsuite] Fix minimal encodings KPASSes"
commit 61049d1ee59905589b2ad3f8140a2582e01add7a
|
|
Consider test-case gdb.base/vla-optimized-out.exp, compiled using clang-10.
GDB fails to get the size of the vla a:
...
(gdb) p sizeof (a)^M
Cannot access memory at address 0x6^M
(gdb) FAIL: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
The relevant DWARF looks like this: the variable a:
...
<2><12b>: Abbrev Number: 5 (DW_TAG_variable)
<12c> DW_AT_name : a
<132> DW_AT_type : <0x189>
...
has type:
...
<1><189>: Abbrev Number: 10 (DW_TAG_array_type)
<18a> DW_AT_type : <0x198>
<2><18e>: Abbrev Number: 11 (DW_TAG_subrange_type)
<18f> DW_AT_type : <0x19f>
<193> DW_AT_count : <0x117>
...
with the count attribute equated to the value of this artificial variable:
...
<2><117>: Abbrev Number: 4 (DW_TAG_variable)
<118> DW_AT_location : 10 byte block: 75 1 10 ff ff ff ff f 1a 9f \
(DW_OP_breg5 (rdi): 1;
DW_OP_constu: 4294967295;
DW_OP_and;
DW_OP_stack_value)
<123> DW_AT_name : __vla_expr0
<127> DW_AT_type : <0x182>
<12b> DW_AT_artificial : 1
...
The location description of the variable is terminated with DW_OP_stack_value,
which according to the DWARF spec means that "the DWARF expression represents
the actual value of the object, rather than its location".
However, in attr_to_dynamic_prop, we set is_reference to true:
...
baton->locexpr.is_reference = true;
...
and use it in dwarf2_evaluate_property to dereference the value of the DWARF
expression, which causes the access to memory at address 0x6.
Fix this by ignoring the baton->locexpr.is_reference == true setting if
the expression evaluation has ctx.location == DWARF_VALUE_STACK, such that we
get:
...
(gdb) p sizeof (a)^M
$2 = 6^M
(gdb) PASS: gdb.base/vla-optimized-out.exp: o1: printed size of \
optimized out vla
...
Tested on x86_64-linux, with gcc.
Tested the following test-cases (the ones mentioned in PR26905) on
x86_64-linux with clang-10:
- gdb.base/vla-optimized-out.exp
- gdb.base/vla-ptr.exp
- gdb.mi/mi-vla-c99
gdb/ChangeLog:
2020-11-30 Tom de Vries <tdevries@suse.de>
PR symtab/26905
* dwarf2/loc.c (dwarf2_locexpr_baton_eval): Add and handle
is_reference parameter.
(dwarf2_evaluate_property): Update dwarf2_locexpr_baton_eval call.
gdb/testsuite/ChangeLog:
2020-11-30 Tom de Vries <tdevries@suse.de>
PR symtab/26905
* gdb.dwarf2/count.exp: Remove kfails.
|
|
With current master I see a couple of KPASSes:
...
KPASS: gdb.ada/enum_idx_packed.exp: scenario=minimal: ptype small \
(PRMS minimal encodings)
...
KPASS: gdb.ada/mod_from_name.exp: scenario=minimal: print xp \
(PRMS minimal encodings)
KPASS: gdb.ada/pckd_arr_ren.exp: scenario=minimal: print var \
(PRMS minimal encodings)
...
The corresponding setup_kfail is called for everything before gnat 11.
However, the test-cases also PASS for me with gnat-4.8, gnat-7.5.0 and
gnat-8.4.0.
Fix the KPASSes by limiting the setup_kfail to gnat 9 and 10.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-16 Tom de Vries <tdevries@suse.de>
* gdb.ada/enum_idx_packed.exp: Limit setup_kfail to gnat 9 and 10.
* gdb.ada/mod_from_name.exp: Same.
* gdb.ada/pckd_arr_ren.exp: Same.
|
|
Breakpoint locations are sorted according to their addresses. The
addresses are determined by how the compiler emits the code.
Therefore, we may have a different order of locations depending on the
compiler we use. To make the gdb.base/condbreak-multi-context.exp
test flexible enough for different compilers' output, do not hard-code
location indices.
Tested with GCC and Clang.
gdb/testsuite/ChangeLog:
2020-11-24 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Do not hard-code location
indices.
|
|
This commit enhances print_type_scalar to include support for
TYPE_CODE_FIXED_POINT. This way, any language falling back to
this function for printing the description of some types
also gets basic ptype support for fixed point types as well.
This fixes a couple of XFAILs in gdb.dwarf2/dw2-fixed-point.exp.
gdb/ChangeLog:
* typeprint.c (print_type_scalar): Add handling of
TYPE_CODE_FIXED_POINT.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-fixed-point.exp: Fix the expected output of
the "ptype pck__fp1_range_var" test for the module-2 and pascal
languages. Remove the associated setup_xfail.
|
|
Let's say you put this gdb_assert in a test:
gdb_assert "some invalid tcl code"
You just get:
FAIL: gdb.base/template.exp: some invalid tcl code
That's not very easy to debug, since you don't know what's invalid in
your code.
Change gdb_assert to print the error message when catch's return code is
1 (TCL_ERROR). The "warning" is shown both on stdout and in the log
file. Mark the test as unresolved, because the evaluation error means
we couldn't reach a valid pass/fail conclusion.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_assert): Show error message on error.
Change-Id: Ie6477859554e909ed8d07fb2769c6f2f55e7cce6
|
|
With current master I see a couple of KPASSes:
...
KPASS: gdb.ada/enum_idx_packed.exp: scenario=minimal: ptype small \
(PRMS minimal encodings)
...
KPASS: gdb.ada/mod_from_name.exp: scenario=minimal: print xp \
(PRMS minimal encodings)
KPASS: gdb.ada/pckd_arr_ren.exp: scenario=minimal: print var \
(PRMS minimal encodings)
...
The corresponding setup_kfail is called for everything before gnat 11.
However, the test-cases also PASS for me with gnat-4.8, gnat-7.5.0 and
gnat-8.4.0.
Fix the KPASSes by limiting the setup_kfail to gnat 9 and 10.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-23 Tom de Vries <tdevries@suse.de>
* gdb.ada/enum_idx_packed.exp: Limit setup_kfail to gnat 9 and 10.
* gdb.ada/mod_from_name.exp: Same.
* gdb.ada/pckd_arr_ren.exp: Same.
|
|
The wiki contains a template for new test cases:
https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Building_the_Example_Program
... which is helpful, because even after many years I can't write all
the boilerplate for writing a test case without doing some mistakes.
However, I think it would be nice to have it in the tree. It's much
faster to cp the files than going to the wiki and copy/pasting the
contents.
As a bonus, the copyright years will get updated in these files, unlike
those in the wiki. So they will always be good when we start a new
test.
If this patch is merged, I plan to change the wiki to just point to
these files.
gdb/testsuite/ChangeLog:
* gdb.base/template.exp: New.
* gdb.base/template.c: New.
Change-Id: I7dbf068a043b48f83cc325087d70e868eee998c6
|
|
Clang describes the upper bounds of variable length arrays using
a DW_AT_count attribute which references the DIE of a synthetic
variable whose value is specified using a DW_AT_location. GDB handles
these incorrectly if the corresponding DWARF expression finishes with a
DW_OP_stack_value (PR26905). This commit adds a new kfailed test to
gdb.dwarf2/count.exp with the same DWARF as that generated by Clang for
gdb.base/vla-optimized-out.exp, one of the failing tests.
Checked on Fedora 32 x86_64, with GCC and Clang.
gdb/testsuite/ChangeLog:
2020-11-22 Gary Benson <gbenson@redhat.com>
PR gdb/26905
* gdb.dwarf2/count.exp: Add test for an array whose upper bound
is defined using a DW_AT_count which references another DIE.
|
|
When running gdb.base/vla-ptr.exp with clang-10, we run into this FAIL:
...
(gdb) print td_vla^M
$6 = 0x7fffffffd2b0^M
(gdb) FAIL: gdb.base/vla-ptr.exp: print td_vla
...
Clang 10.0.1 generates the following DWARF for td_vla. A variable DIE:
...
<2><19f>: Abbrev Number: 6 (DW_TAG_variable)
<1a0> DW_AT_location : 0x39 (location list)
<1a4> DW_AT_name : td_vla
<1aa> DW_AT_type : <0x1ae>
....
with typedef type:
...
<2><1ae>: Abbrev Number: 7 (DW_TAG_typedef)
<1af> DW_AT_type : <0x1fc>
<1b3> DW_AT_name : typedef_vla
...
pointing to:
...
<1><1fc>: Abbrev Number: 11 (DW_TAG_array_type)
<1fd> DW_AT_type : <0x1d3>
<2><201>: Abbrev Number: 14 (DW_TAG_subrange_type)
<202> DW_AT_type : <0x1f5>
...
The subrange type is missing the count attribute. This was filed as
llvm PR48247 - "vla var with typedef'd type has incomplete debug info".
Mark this as xfail.
gdb/testsuite/ChangeLog:
2020-11-21 Tom de Vries <tdevries@suse.de>
* gdb.base/vla-ptr.exp: Add XFAIL.
|
|
This commit brings array slice support to GDB.
WARNING: This patch contains a rather big hack which is limited to
Fortran arrays, this can be seen in gdbtypes.c and f-lang.c. More
details on this below.
This patch rewrites two areas of GDB's Fortran support, the code to
extract an array slice, and the code to print an array.
After this commit a user can, from the GDB prompt, ask for a slice of
a Fortran array and should get the correct result back. Slices can
(optionally) have the lower bound, upper bound, and a stride
specified. Slices can also have a negative stride.
Fortran has the concept of repacking array slices. Within a compiled
Fortran program if a user passes a non-contiguous array slice to a
function then the compiler may have to repack the slice, this involves
copying the elements of the slice to a new area of memory before the
call, and copying the elements back to the original array after the
call. Whether repacking occurs will depend on which version of
Fortran is being used, and what type of function is being called.
This commit adds support for both packed, and unpacked array slicing,
with the default being unpacked.
With an unpacked array slice, when the user asks for a slice of an
array GDB creates a new type that accurately describes where the
elements of the slice can be found within the original array, a
value of this type is then returned to the user. The address of an
element within the slice will be equal to the address of an element
within the original array.
A user can choose to select packed array slices instead using:
(gdb) set fortran repack-array-slices on|off
(gdb) show fortran repack-array-slices
With packed array slices GDB creates a new type that reflects how the
elements of the slice would look if they were laid out in contiguous
memory, allocates a value of this type, and then fetches the elements
from the original array and places then into the contents buffer of
the new value.
One benefit of using packed slices over unpacked slices is the memory
usage, taking a small slice of N elements from a large array will
require (in GDB) N * ELEMENT_SIZE bytes of memory, while an unpacked
array will also include all of the "padding" between the
non-contiguous elements. There are new tests added that highlight
this difference.
There is also a new debugging flag added with this commit that
introduces these commands:
(gdb) set debug fortran-array-slicing on|off
(gdb) show debug fortran-array-slicing
This prints information about how the array slices are being built.
As both the repacking, and the array printing requires GDB to walk
through a multi-dimensional Fortran array visiting each element, this
commit adds the file f-array-walk.h, which introduces some
infrastructure to support this process. This means the array printing
code in f-valprint.c is significantly reduced.
The only slight issue with this commit is the "rather big hack" that I
mentioned above. This hack allows us to handle one specific case,
array slices with negative strides. This is something that I don't
believe the current GDB value contents model will allow us to
correctly handle, and rather than rewrite the value contents code
right now, I'm hoping to slip this hack in as a work around.
The problem is that, as I see it, the current value contents model
assumes that an object base address will be the lowest address within
that object, and that the contents of the object start at this base
address and occupy the TYPE_LENGTH bytes after that.
( We do have the embedded_offset, which is used for C++ sub-classes,
such that an object can start at some offset from the content buffer,
however, the assumption that the object then occupies the next
TYPE_LENGTH bytes is still true within GDB. )
The problem is that Fortran arrays with a negative stride don't follow
this pattern. In this case the base address of the object points to
the element with the highest address, the contents of the array then
start at some offset _before_ the base address, and proceed for one
element _past_ the base address.
As the stride for such an array would be negative then, in theory the
TYPE_LENGTH for this type would also be negative. However, in many
places a value in GDB will degrade to a pointer + length, and the
length almost always comes from the TYPE_LENGTH.
It is my belief that in order to correctly model this case the value
content handling of GDB will need to be reworked to split apart the
value's content buffer (which is a block of memory with a length), and
the object's in memory base address and length, which could be
negative.
Things are further complicated because arrays with negative strides
like this are always dynamic types. When a value has a dynamic type
and its base address needs resolving we actually store the address of
the object within the resolved dynamic type, not within the value
object itself.
In short I don't currently see an easy path to cleanly support this
situation within GDB. And so I believe that leaves two options,
either add a work around, or catch cases where the user tries to make
use of a negative stride, or access an array with a negative stride,
and throw an error.
This patch currently goes with adding a work around, which is that
when we resolve a dynamic Fortran array type, if the stride is
negative, then we adjust the base address to point to the lowest
address required by the array. The printing and slicing code is aware
of this adjustment and will correctly slice and print Fortran arrays.
Where this hack will show through to the user is if they ask for the
address of an array in their program with a negative array stride, the
address they get from GDB will not match the address that would be
computed within the Fortran program.
gdb/ChangeLog:
* Makefile.in (HFILES_NO_SRCDIR): Add f-array-walker.h.
* NEWS: Mention new options.
* f-array-walker.h: New file.
* f-lang.c: Include 'gdbcmd.h' and 'f-array-walker.h'.
(repack_array_slices): New static global.
(show_repack_array_slices): New function.
(fortran_array_slicing_debug): New static global.
(show_fortran_array_slicing_debug): New function.
(value_f90_subarray): Delete.
(skip_undetermined_arglist): Delete.
(class fortran_array_repacker_base_impl): New class.
(class fortran_lazy_array_repacker_impl): New class.
(class fortran_array_repacker_impl): New class.
(fortran_value_subarray): Complete rewrite.
(set_fortran_list): New static global.
(show_fortran_list): Likewise.
(_initialize_f_language): Register new commands.
(fortran_adjust_dynamic_array_base_address_hack): New function.
* f-lang.h (fortran_adjust_dynamic_array_base_address_hack):
Declare.
* f-valprint.c: Include 'f-array-walker.h'.
(class fortran_array_printer_impl): New class.
(f77_print_array_1): Delete.
(f77_print_array): Delete.
(fortran_print_array): New.
(f_value_print_inner): Update to call fortran_print_array.
* gdbtypes.c: Include 'f-lang.h'.
(resolve_dynamic_type_internal): Call
fortran_adjust_dynamic_array_base_address_hack.
gdb/testsuite/ChangeLog:
* gdb.fortran/array-slices-bad.exp: New file.
* gdb.fortran/array-slices-bad.f90: New file.
* gdb.fortran/array-slices-sub-slices.exp: New file.
* gdb.fortran/array-slices-sub-slices.f90: New file.
* gdb.fortran/array-slices.exp: Rewrite tests.
* gdb.fortran/array-slices.f90: Rewrite tests.
* gdb.fortran/vla-sizeof.exp: Correct expected results.
gdb/doc/ChangeLog:
* gdb.texinfo (Debugging Output): Document 'set/show debug
fortran-array-slicing'.
(Special Fortran Commands): Document 'set/show fortran
repack-array-slices'.
|
|
Switch over to using new option processing mechanism for watch,
awatch, and rwatch commands. Add command completion function.
This means that expression completion now works correctly when the
-location flag is used. So previously:
(gdb) watch var.<TAB><TAB>
.... list fields of var ....
But,
(gdb) watch -location var.<TAB><TAB>
.... list all symbols ....
After this commit only the fields of 'var' are listed even when
'-location' is passed.
Another benefit of this change is that '-location' will now complete.
One thing to note is that previous these commands accepted both
'-location' or '-l' (these being synonyms). The new option scheme
doesn't really allow for official short form flags, however, it does
allow for non-ambiguous sub-strings to be used. What this means is
that currently (as these commands only have the '-location' flag) the
user can still use '-l', so there's no change there.
The interactive help text for these commands now emphasises
'-location' as the real option, but does mention that '-l' can also be
used.
gdb/ChangeLog:
* breakpoint.c (struct watch_options): New struct.
(watch_option_defs): New static global.
(make_watch_options_def_group): New function.
(watch_maybe_just_location): Convert option parsing.
(watch_command_completer): New function.
(_initialize_breakpoint): Build help text using options mechanism.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add new completion tests.
|
