gdb.base/structs2.exp fails to run with Clang, because of:
gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:14: warning:
implicit conversion from 'int' to 'signed char' changes value from 130 to
-126 [-Wconstant-conversion]
param_reg (130, 120, 33000, 32000);
~~~~~~~~~ ^~~
/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/structs2.c:16:24: warning:
implicit conversion from 'int' to 'short' changes value from 33000 to
-32536 [-Wconstant-conversion]
param_reg (130, 120, 33000, 32000);
~~~~~~~~~ ^~~~~
2 warnings generated.
=== gdb Summary ===
# of untested testcases 1
Fix it by passing actual negative numbers.
gdb/testsuite/ChangeLog:
* gdb.base/structs2.c (main): Adjust second parem_reg call to
explicitly write negative numbers.
* gdb.base/structs2.exp: Adjust expected output.
gdb.base/charset.exp fails to run with Clang, because of:
gdb compile failed, /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:144:20: warning:
implicit conversion from 'int' to 'char' changes value from 162 to -94
[-Wconstant-conversion]
11, 162, 17);
^~~
/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:151:16: warning:
implicit conversion from 'int' to 'char' changes value from 167 to -89
[-Wconstant-conversion]
167,
^~~
/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/charset.c:168:16: warning:
implicit conversion from 'int' to 'char' changes value from 167 to -89
[-Wconstant-conversion]
167,
^~~
3 warnings generated.
=== gdb Summary ===
# of untested testcases 1
Fix it by changing init_string to take unsigned char parameters.
gdb/testsuite/ChangeLog:
* gdb.base/charset.c (init_string): Change all char parameters to
unsigned char parameters.
The gdb.base/call-sc.exp, gdb.base/structs.exp and
gdb.base/structs2.exp testcases still try compiling the sources with
-DNO_PROTOTYPES, but the corresponding sources don't have any #ifdef
NO_PROTOTYPES any longer. Those were removed throughout years ago.
OTOH, gdb.base/ovlymgr.h does check for NO_PROTOTYPES, but no .exp
file compiles it with -DNO_PROTOTYPES.
gdb.base/reread.exp and gdb.base/varargs.exp set a 'prototypes'
global, which is a stale bit left behind when the "try-compiling
without and then with -DNO_PROTOTYPES" logic was around.
gdb/testsuite/ChangeLog:
* gdb.base/call-sc.exp (start_scalars_test): Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
* gdb.base/overlays.c: Remove references to PARAMS.
* gdb.base/ovlymgr.h (PARAMS): Delete, and remove all references.
* gdb.base/reread.exp: Don't set 'prototypes' global.
* gdb.base/structs.exp (start_structs_test): Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
* gdb.base/structs2.exp: Don't set 'prototypes' global. Use
prepare_for_testing and don't try compiling with -DNO_PROTOTYPES.
Don't issue "set width 0". Remove gdb_stop_suppressing_tests
call.
* gdb.base/varargs.exp: Don't set 'prototypes' global.
D10V support was removed years ago, but the gdb.base/d10vovly.c file
stayed behind. Looking a bit closer, I can't find anywhere that
references gdb.base/m32rovly.c either.
Both gdb.base/m32rovly.c and gdb.base/d10vovly.c seem to be older
copies of gdb.base/ovlymgr.c, that are exactly the same, except for
some cosmetic differences, and for missing _ovly_debug_event. Note
that gdb.base/ovlymgr.c has the #ifdef __M32R__ bits too. Note also
that gdb.base/overlays.exp is currently only supported on m32r, and
that uses ovlymgr.c not gdb.base/m32rovly.c.
gdb/testsuite/ChangeLog:
* gdb.base/d10vovly.c: Delete.
* gdb.base/m32rovly.c: Delete.
* gdb.base/ovlymgr.c: Remove all code guarded by __D10V__.
This fixes test runs and compilation when --disable-libctf,
--disable-static, or --enable-shared are passed.
Changes since v2: Use GCC_ENABLE and fix indentation. Fix prototype
using 'void'. Use 'unsupported' and gdb_caching_proc.
Changes since v3: Adapt to upstream changes providing skip_ctf_tests.
Changes since v4: Adapt to upstream changes in the seven months (!)
since I last looked at this.
gdb/ChangeLog
* configure.ac: Add --enable-libctf: handle --disable-static
properly.
* acinclude.m4: sinclude ../config/enable.m4.
* Makefile.in (aclocal_m4_deps): Adjust accordingly.
(LIBCTF): Substitute in.
(CTF_DEPS): New, likewise.
(CLIBS): libctf needs symbols from libbfd: move earlier.
(CDEPS): Use CTF_DEPS, not LIBCTF, now LIBCTF can include rpath
flags.
* ctfread.c: Surround in ENABLE_LIBCTF.
(elfctf_build_psymtabs) [!ENABLE_LIBCTF]: New stub.
* configure: Regenerate.
* config.in: Likewise.
gdb/testsuite/ChangeLog
* configure.ac: Add --enable-libctf.
* aclocal.m4: sinclude ../config/enable.m4.
* Makefile.in (site.exp): Add enable_libctf to site.exp.
* lib/gdb.exp (skip_ctf_tests): Use it.
* gdb.base/ctf-constvars.exp: Error message tweak.
* gdb.base/ctf-ptype.exp: Likewise.
* configure: Regenerate.
Test the new default-args behaviour and completion for the alias command.
Note that gdb.base/default-args.exp is somewhat copied from
with.exp (the test of the with command), while default-exp.c
is a plain copy of with.c.
gdb/testsuite/ChangeLog
2020-06-22 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/default-args.exp: New test.
* gdb.base/default-args.c: New file.
* gdb.base/alias.exp: Update expected error msg for alias foo=bar.
* gdb.base/default.exp: Update to new help text.
* gdb.base/help.exp: Likewise.
* gdb.base/page.exp: Likewise.
* gdb.base/style.exp: Likewise.
* gdb.guile/guile.exp: Likewise.
* gdb.python/python.exp: Likewise.
One set of tests in this file does a lot of complicated directory
manipulations to force a specific DW_AT_comp_dir format and gdb
directory search path. As it's written, everything assumes host ==
build, and it does not seem to me that there is any obvious way to
rewrite this so it will work in general on remote host. For instance,
our harness for testing on remote Windows host normally does all
compilation and GDB execution in $cwd using relative pathnames and I'm
not sure all these directory tricks would set up the scenario it's
trying to test even if they were correctly performed on host rather
than build. So I think it's reasonable just to disable this on remote
host instead.
I also noted that it's using the wrong search path syntax for Windows
host in the "set directories" command and conditionalized that while I
was looking at it. That's a necessary fix to make this work in a
situation where host == build and it's Windows, but I'm not actually
set up to test that it's sufficient, too.
2020-06-22 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.base/source-dir.exp (test_truncated_comp_dir): Skip on
remote host. Fix search path syntax on Windows host.
Following the implementation of exec-file-mismatch based on build-id,
an attach to a process that runs a modified exec-file was triggering
the exec-file-mismatch handling, giving a warning such as:
warning: Mismatch between current exec-file /bd/home/philippe/gdb/git/build_termours/gdb/testsuite/outputs/gdb.base/attach/attach
and automatically determined exec-file /bd/home/philippe/gdb/git/build_termours/gdb/testsuite/outputs/gdb.base/attach/attach
exec-file-mismatch handling is currently "ask"
as the build-ids differ when an exec-file is recompiled.
This patch ensures that the exec-file-mismatch check is done with an up to date
build-id. With this, exec-file-mismatch check will only trigger when the
PID file really differs from the (build-id refreshed) current exec-file.
Note that the additional check does not (yet) reload the symbols if
the exec-file is changed: this reload will happen later if needed.
gdb/ChangeLog
2020-06-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* exec.c (validate_exec_file): Ensure the build-id is up to
date by calling reopen_exec_file (that checks file timestamp
to decide to re-read the file).
gdb/testsuite/ChangeLog
2020-06-21 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/attach.exp: Test priority of 'exec-file' changed
over 'exec-file-mismatch'.
* gdb.base/attach.c: Mark should_exit volatile.
* gdb.base/attach2.c: Likewise. Add a comment explaining
why the sleep cannot be big.
* gdb.base/attach3.c: New file.
This patch fixes an internal error that is triggered when loading the
same binary twice with the index-cache on:
$ ./gdb -q -nx --data-directory=data-directory
(gdb) set index-cache on
(gdb) shell mktemp -d
/tmp/tmp.BLgouVoPq4
(gdb) set index-cache directory /tmp/tmp.BLgouVoPq4
(gdb) file a.out
Reading symbols from a.out...
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...
/home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:2540: internal-error: void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, const gdb_byte*, offset_type): Assertion `per_bfd->all_comp_units.empty ()' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
This is what happens:
1. We load the binary the first time, partial symtabs are created,
per_bfd->all_comp_units is filled from those.
2. Because index-cache is on, we also generate an index in the cache.
3. We load the binary a second time, in dwarf2_initialize_objfile we
check: was an index already loaded for this BFD? No, so we try to
read the index and fill the per-bfd using it. We do find an index,
it's in the cache.
4. The function create_cus_from_index asserts (rightfully) that
per_cu->all_comp_units is empty, and the assertion fails.
This assertion verifies that we are not reading an index for a BFD for
which we have already built partial symtabs or read another index.
The index-cache gives a situation that isn't currently accounted for: a
BFD for which we have built the partial symtabs the first time, but has
an index the second time.
This patch addresses it by checking for the presence of partial symtabs
in dwarf2_initialize_objfile. If there are, we don't try reading the
index.
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_initialize_objfile): Check for presence
of partial symtabs.
gdb/testsuite/ChangeLog:
* gdb.base/index-cache-load-twice.c: New.
* gdb.base/index-cache-load-twice.exp: New.
Change-Id: Ie05474c44823fcdff852b73170dd28dfd66cb6a2
gdb/testsuite/ChangeLog:
2020-06-15 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/jit-elf-so.exp: Refer to the global main_loader_basename
variable.
* gdb.base/jit-reader-simple.exp: Fix typo ("Built" -> "Build"),
and use the already-defined 'options' variable.
PR gdb/18318 notes that gdb will sometimes incorrectly handle hex
floating point input. This turns out to be a bug in the C lexer; the
'p' was not being correctly recognized, and so the exponent was not
always passed to the floating point "from_string" method.
Tested by the buildbot "Fedora-x86_64-m64" builder.
gdb/ChangeLog
2020-06-11 Tom Tromey <tom@tromey.com>
PR gdb/18318:
* c-exp.y (lex_one_token): Handle 'p' like 'e'.
gdb/testsuite/ChangeLog
2020-06-11 Tom Tromey <tom@tromey.com>
PR gdb/18318:
* gdb.base/printcmds.exp (test_float_accepted): Add more hex
floating point tests.
This patch fixes gdb/21356 in which we hit an assertion in
value_contents_bits_eq:
(gdb) p container_object2
(gdb) p container_object2
$1 = {_container_member2 = 15, _vla_struct_object2 = {_some_member = 0,
_vla_field = {
../../src/gdb/value.c:829: internal-error: \
int value_contents_bits_eq(const value*, int, const value*, int, int): \
Assertion `offset1 + length \
<= TYPE_LENGTH (val1->enclosing_type) * TARGET_CHAR_BIT' failed.
This is happening because TYPE_LENGTH (val1->enclosing_type) is erroneously
based on enclosing_type, which is a typedef, instead of the actual underlying
type.
This can be traced back to resolve_dynamic_struct, where the size of the
type is computed:
...
TYPE_FIELD_TYPE (resolved_type, i)
= resolve_dynamic_type_internal (TYPE_FIELD_TYPE (resolved_type, i),
&pinfo, 0);
gdb_assert (TYPE_FIELD_LOC_KIND (resolved_type, i)
== FIELD_LOC_KIND_BITPOS);
new_bit_length = TYPE_FIELD_BITPOS (resolved_type, i);
if (TYPE_FIELD_BITSIZE (resolved_type, i) != 0)
new_bit_length += TYPE_FIELD_BITSIZE (resolved_type, i);
else
new_bit_length += (TYPE_LENGTH (TYPE_FIELD_TYPE (resolved_type, i))
* TARGET_CHAR_BIT);
...
In this function, resolved_type is TYPE_CODE_TYPEDEF which is not what we
want to use to calculate the size of the actual field.
This patch fixes this and the similar problem in resolve_dynamic_union.
gdb/ChangeLog:
2020-06-11 Keith Seitz <keiths@redhat.com>
PR gdb/21356
* gdbtypes.c (resolve_dynamic_union, resolve_dynamic_struct):
Resolve typedefs for type length calculations.
gdb/testsuite/ChangeLog:
2020-06-11 Keith Seitz <keiths@redhat.com>
PR gdb/21356
* gdb.base/vla-datatypes.c (vla_factory): Add typedef for struct
vla_struct.
Add new struct vla_typedef and union vla_typedef_union and
corresponding instantiation objects.
Initialize new objects.
* gdb.base/vla-datatypes.exp: Add tests for vla_typedef_struct_object
and vla_typedef_union_object.
Fixup type for vla_struct_object.
Test-case gdb.base/dbx.exp overrides:
- the GDBFLAGS variable
- the gdb_file_cmd proc
There's code at the end of the test-case to restore both, but that's not
guaranteed to be executed.
Fix this by:
- using save_vars to restore GDBFLAGS
- using a new proc with_override to restore gdb_file_cmd
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-11 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (with_override): New proc, factored out of ...
* gdb.base/dbx.exp: ... here. Use with_override and save_vars.
Fix:
DUPLICATE: gdb.base/index-cache.exp: test_cache_disabled: no files were created
DUPLICATE: gdb.base/index-cache.exp: test_cache_disabled: check index-cache stats
We use `proc_with_prefix` for test_cache_disabled, but we call it twice. So we
need an additional prefix to identify the specific call. This patch adds that.
gdb/testsuite/ChangeLog:
* gdb.base/index-cache.exp (test_cache_disabled): Add test_prefix
parameter, update callers.
Change-Id: Idf382fd380c77a654e8a7aa236af50b65c96b1d2
Fix/follow-up to commit 17ee85fc2a ("Share DWARF partial symtabs").
In the non-index case, where GDB builds partial symbols from scratch,
two objfiles around the same BFD correctly share partial symtabs. The
first objfile, which has to do all the work, saves a reference to the
created partial symtabs in the shared per_bfd object (at the end of
dwarf2_build_psymtabs). The second objfile, when it reaches
dwarf2_build_psymtabs, sees that there are already partial symtabs built
for this BFD and just uses it.
However, that commit missed implementing the same sharing for cases
where GDB uses .gdb_index or .debug_names to build the partial symtabs.
This patch fixes it by having the first objfile to use the BFD set
per_bfd->partial_symtabs at the end of dwarf2_read_gdb_index /
dwarf2_read_debug_names. For the subsequent objfiles using that BFD,
the partial symtabs are then picked up in dwarf2_initialize_objfile.
This patch adds a test that mimics how the issue was originally
triggered:
1. Load the test file twice, such that the second objfile re-uses the
per_bfd object created for the first objfile.
2. Run to some point where in the backtrace there is a frame for a
function that's in a CU that's not yet read in.
3. Check that this frame's information is complete in the "backtrace"
output.
Step 2 requires an address -> symbol lookup which uses the addrmap at
objfile->partial_symtabs->psymtabs_addrmap. If the
objfile->partial_symtabs link is not properly setup (as is the case
before this patch), the symbol for that frame won't be found and we'll
get a frame with incomplete information.
The test fails without the fix when using boards "cc-with-gdb-index" and
"cc-with-debug-names".
gdb/ChangeLog:
* dwarf2/read.c (dwarf2_read_gdb_index): Save partial_symtabs in
the per_bfd object.
(dwarf2_read_debug_names): Likewise.
(dwarf2_initialize_objfile): Use partial_symtabs from per_bfd
object when re-using a per_bfd object with an index.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/share-psymtabs-bt.exp: New file.
* gdb.dwarf2/share-psymtabs-bt.c: New file.
* gdb.dwarf2/share-psymtabs-bt-2.c: New file.
Change-Id: Ibb26210e2dfc03b80ba9fa56b875ba4cc58c0352
When running the gdb/jit-*.exp tests with runtest -v, I get:
...
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf-so.exp: one_jit_test-1: maintenance print objfiles
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf-so.exp: one_jit_test-2: maintenance print objfiles
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf.exp: one_jit_test-1: maintenance print objfiles
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf.exp: one_jit_test-2: maintenance print objfiles
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf.exp: attach: one_jit_test-2: maintenance print objfiles
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/jit-elf.exp: PIE: one_jit_test-1: maintenance print objfiles
FAIL: gdb.base/jit-reader.exp: jit-reader-load
FAIL: gdb.base/jit-reader.exp: with jit-reader: before mangling: bt works
FAIL: gdb.base/jit-reader.exp: with jit-reader: after mangling: bt works
FAIL: gdb.base/jit-reader.exp: with jit-reader again: jit-reader-load
FAIL: gdb.base/jit-reader.exp: with jit-reader again: bt
...
This is the consequence of the use of global verbose in these tests, which is
used to change the actual test, rather than be more verbose about it.
Fix this by defining a global test_verbose in each test, and using that
instead.
Tested on x86_64-linux using runtest -v.
gdb/testsuite/ChangeLog:
2020-06-03 Tom de Vries <tdevries@suse.de>
PR testsuite/25609
* gdb.base/jit-elf-so.exp: Don't modify testing behaviour based on
value of global verbose.
* gdb.base/jit-elf.exp: Same.
* gdb.base/jit-reader.exp: Same.
When running the testsuite with clang, gdb.base/sigaltstack.c
fails to compile with the following error:
warning: enumeration values 'LEAF' and 'NR_LEVELS' not handled
in switch [-Wswitch]
This prevents the gdb.base/sigaltstack.exp from executing.
This commit fixes.
gdb/testsuite/ChangeLog:
* gdb.base/sigaltstack.c (catcher): Add default case to switch
statement.
While doing a testsuite run on aarch64-linux, I noticed a bunch of duplicated
test name results. It annoyed me a little, so I decided to go ahead and fix the
worst offenders.
The following patch brings the duplicate test names down from 461 to 137.
The remaining ones are mostly scattered across the testsuite, with 1 to 3
duplicates per testcase. We can fix those as we go.
gdb/testsuite/ChangeLog:
2020-05-27 Luis Machado <luis.machado@linaro.org>
* gdb.arch/aarch64-sighandler-regs.exp: Fix duplicated test names.
* gdb.arch/aarch64-tagged-pointer.exp: Likewise.
* gdb.arch/arm-disassembler-options.exp: Likewise.
* gdb.arch/arm-disp-step.exp: Likewise.
* gdb.arch/thumb-prologue.exp: Likewise.
* gdb.base/async.exp: Likewise.
* gdb.base/auxv.exp: Likewise.
* gdb.base/complex-parts.exp: Likewise.
* gdb.base/ena-dis-br.exp: Likewise.
* gdb.base/foll-exec.exp: Likewise.
* gdb.base/permissions.exp: Likewise.
* gdb.base/relocate.exp: Likewise.
* gdb.base/return2.exp: Likewise.
* gdb.base/sigbpt.exp: Likewise.
* gdb.base/siginfo-obj.exp: Likewise.
* gdb.cp/converts.exp: Likewise.
* gdb.cp/exceptprint.exp: Likewise.
* gdb.cp/inherit.exp: Likewise.
* gdb.cp/nsnoimports.exp: Likewise.
* gdb.cp/virtbase2.exp: Likewise.
* gdb.mi/mi-var-cmd.exp: Likewise.
* gdb.mi/var-cmd.c: Likewise.
There's a PR binutils/15646 - "gold-generated .gdb_index has duplicated
symbols that gdb-generated index doesn't", and gdb contains a workaround,
added in commit 8943b87476 "Work around gold/15646".
Add a test-case testing this workaround.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-26 Tom de Vries <tdevries@suse.de>
* gdb.base/gold-gdb-index-2.c: New test.
* gdb.base/gold-gdb-index.c: New test.
* gdb.base/gold-gdb-index.exp: New file.
* gdb.base/gold-gdb-index.h: New test.
Add a test for verifying different methods of passing arguments to the
inferior: the start, starti and run commands, as well as `set args`.
All these methods work naturally when using the unix or
native-extended-gdbserver target boards. Since those are non-stub
boards, GDB runs new inferiors and therefore pass arguments to them.
With target boards where GDB connects to a stub, for example with
native-gdbserver, they don't really make sense. The inferior process is
already started when GDB connects.
However, the "run" method is still tested with stub targets, because the
gdb_run_cmd procedure is adapted for stub targets. Instead of issuing
the `run` command, it spawns whatever program is supposed to bring up
the stub (gdbserver, for example) using gdb_reload and makes GDB connect
to it. So this allows us to exercise argument passing through the
gdbserver command line, when testing with the native-gdbserver board.
Note that there is already a gdb.base/args.exp, but this tests
specifically the --args switch of GDB. Perhaps it could be integrated
in this new test, as a new "method".
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_run_cmd): Return success or failure.
* gdb.base/inferior-args.exp: New file.
* gdb.base/inferior-args.c: New file.
Change-Id: Ib61ea6220a47f9f67aed2960dcacd240cb57af70
This patch makes it possible to run tests requiring passing arguments to
the inferior with the native-gdbserver board. The end goal is to write
a test that verifies passing arguments to the inferior works, and to
have that test exercise inferior arguments passed on the gdbserver
command line, when using the native-gdbserver target board (in addition
to the other boards). This is done in the next patch.
With the native-gdbserver target board, gdbserver is started in
gdb_reload (implemented in config/gdbserver.exp), called in gdb_run_cmd.
gdb_run_cmd already supposedly accepts inferior arguments (although that
feature does not seem to be used anywhere), which it passes to the `run`
command, for non-stub target boards. I've changed gdb_run_cmd so that
it forwards these arguments to gdb_reload as well. gdb_reload passes
them to gdbserver_run, and they eventually make their way to the
gdbserver command line.
gdb_run_cmd currently accepts `args` (the varargs of tcl), which means
it receives inferior arguments as a list. This won't work with
arguments with spaces, because they will end up being formatted with
curly braces like this:
% set args [list hello "with spaces" world]
hello {with spaces} world
% puts "run $args"
run hello {with spaces} world
I've changed it to accept a single string that is passed to `run` and
gdb_reload. I've done the same change in gdb_start_cmd and
gdb_starti_cmd, although these two are not used with native-gdbserver.
I've changed all gdb_reload implementations in the tree to accept a new
inferior_args argument, although most of them don't do anything with it
(and don't need to). People maintaining target boards out of tree will
need to do the same.
I found two tests to adjust to avoid adding new failures or errors.
These tests needed new [use_gdb_stub] checks, because they rely on
having GDB run new processes. These are guarded by a [target_info
exists noargs], which made them get skipped on native-gdbserver. But
now that the native-gdbserver board supports args, this is no longer
enough.
Note that with this change, noargs and use_gdb_stub are orthogonal. It
took me a moment to grasp this, so I thought I would spell out the
different possible situations:
- !noargs and !use_gdb_stub: inferior process started by gdb, can pass
args
- noargs and !use_gdb_stub: inferior process started by gdb (perhaps
through extended-remote protocol, the simulator, some other target),
but that target doesn't support inferior arguments
- noargs and use_gdb_stub: inferior process started by some other
program to which GDB connects using the remote protocol, that program
does not support passing args to the inferior process
- !noargs and use_gdb_stub: inferior process started by some other
program to which GDB connects u sing the remote protocol, that program
supports passing args to the inferior process
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_run_cmd): Change argument from args to
inferior_args. Pass it to gdb_reload.
(gdb_start_cmd, gdb_starti_cmd): Change argument from args to
inferior_args.
(gdb_reload): Add inferior_args argument.
* config/gdbserver.exp (gdb_reload): Add inferior_args argument,
pass it to gdbserver_run.
* boards/native-gdbserver.exp: Do not set noargs.
* boards/native-extended-gdbserver.exp (gdb_reload): Add
inferior_args argument.
* boards/stdio-gdbserver-base.exp (gdb_reload): Likewise.
* gdb.base/a2-run.exp: Check for use_gdb_stub.
* gdb.base/args.exp: Likewise.
Change-Id: Ibda027c71867157852f34700342ab31edf39e4d8
Readline has a styling feature for completion -- if it is enabled, the
common prefix of completions will be displayed in a different style.
This doesn't work in gdb, because gdb implements its own completer.
This patch implements the feature. However, it doesn't directly use
the Readline feature, because gdb can do a bit better: it can let the
user control the styling using the existing mechanisms.
This version incorporates an Emacs idea, via Eli: style the prefix,
the "difference character", and the suffix differently.
gdb/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* NEWS: Add entry for completion styling.
* completer.c (_rl_completion_prefix_display_length): Move
declaration earlier.
(gdb_fnprint): Use completion_style.
(gdb_display_match_list_1): Likewise.
* cli/cli-style.c (completion_prefix_style)
(completion_difference_style, completion_suffix_style): New
globals.
(_initialize_cli_style): Register new globals.
* cli/cli-style.h (completion_prefix_style)
(completion_difference_style, completion_suffix_style): Declare.
gdb/doc/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Output Styling): Mention completion styling.
(Editing): Mention readline completion styling.
gdb/testsuite/ChangeLog
2020-05-23 Tom Tromey <tom@tromey.com>
* gdb.base/style.exp: Add completion styling test.
* lib/gdb-utils.exp (style): Add completion styles.
This undoes most of the changes from these commits:
commit ec8e2b6d30
Date: Fri Jun 14 23:43:00 2019 +0100
gdb: Don't allow annotations to influence what else GDB prints
commit 0d3abd8cc9
Date: Wed Jun 12 22:34:26 2019 +0100
gdb: Remove an update of current_source_line and current_source_symtab
as a result of the discussion here:
https://sourceware.org/pipermail/gdb/2020-April/048468.html
Having taken time to reflect on the discussion, and reading the
documentation again I believe we should revert GDB's behaviour back to
how it used to be.
The original concern that triggered the initial patch was that when
annotations were on the current source and line were updated (inside
the annotation code), while when annotations are off this update would
not occur. This was incorrect, as printing the source with the call
to print_source_lines does also update the current source and line.
Further, the documentation here:
https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Annotations.html#Source-Annotations
Clearly states:
"The following annotation is used instead of displaying source code:
^Z^Zsource filename:line:character:middle:addr
..."
So it is documented that the 'source' annotation is a replacement for,
and not in addition to, actually printing the source lie.
There are still a few issues that I can see, these are:
1. In source.c:info_line_command, when annotations are on we call
annotate_source_line, however, if annotations are off then there is
no corresponding call to print the source line. This means that a
if a user uses 'info line ...' with annotations on, and then does a
'list', they will get different results than if they had done this
with annotations off.
2. It bothers me that the call to annotate_source_line returns a
boolean, and that this controls a call to print_source_line (in
stack.c:print_frame_info).
The reason for this is that the source line annotation will only
print something if the file is found, and the line number is in
range for the file.
It seems to me like an annotation should always be printed, either
one that identifies the file and line, or one that identifies the
file and line GDB would like to access, but couldn't.
I considered changing this, but in the end decided not too, if I
extend the existing 'source' annotation to print something in all
cases then I risk breaking existing UIs that rely on the file and
line always being valid. If I add a new annotation then this might
also break existing UIs that rely on GDB itself printing the error
from within print_source_line.
Given that annotations is deprecated (as I understand it) mechanism
for UIs to interact with GDB (in favour of MI) I figure we should just
restore the old behaviour, and leave the mini-bugs in until someone
actually complains.
This isn't a straight revert of the two commits mentioned above. I've
left annotate_source_line instead of going back to the original
identify_source_line, which lived in source.c, but was really
annotation related. The API for setting the current source and line
has changed since the original patches, so I updated for that change
too. Finally I wrote the code in stack.c so that we avoided an extra
level of indentation, which I felt made things easier to read.
gdb/ChangeLog:
* annotate.c (annotate_source_line): Update return type, add call
to update current symtab and line.
* annotate.h (annotate_source_line): Update return type, and
extend header comment.
* source.c (info_line_command): Check annotation_level before
calling annotate_source_line.
* stack.c (print_frame_info): If calling annotate_source_line
returns true, then don't print any other source line information.
gdb/testsuite/ChangeLog:
* gdb.base/annota1.exp: Update expected results.
* gdb.cp/annota2.exp: Update expected results, remove duplicate
test name.
* gdb.cp/annota3.exp: Update expected results.
Fixup a few spots in the testsuite that use mmap to consistently check
the return value against MAP_FAILED.
One spot in gdb.base/coredump-filter.c checked against NULL, that is
wrong. The other spots either didn't check, or checked against -1.
MAP_FAILED has the value -1, at least on Linux, but it's better to check
against the documented define.
gdb/testsuite/ChangeLog:
PR gdb/26016
* gdb.base/coredump-filter.c (do_mmap): Check mmap ret val
against MAP_FAILED.
* gdb.base/coremaker.c (mmapdata): Likewise.
* gdb.base/jit-reader-host.c (main): Likewise.
* gdb.base/sym-file-loader.c (load): Likewise.
(load_shlib): Likewise.
When running test-case gdb.base/with.exp with target board cc-with-gdb-index,
we have:
...
(gdb) PASS: gdb.base/with.exp: basics: show language
with language ada -- print g_s^M
'g_s' has unknown type; cast it to its declared type^M
(gdb) FAIL: gdb.base/with.exp: basics: with language ada -- print g_s
...
This is due to this bit in dw2_map_matching_symbols:
...
if (dwarf2_per_objfile->index_table != nullptr)
{
/* Ada currently doesn't support .gdb_index (see PR24713). We can get
here though if the current language is Ada for a non-Ada objfile
using GNU index. As Ada does not look for non-Ada symbols this
function should just return. */
return;
}
...
While the reasoning in the comment may be sound from language perspective, it
does introduce an inconsistency in gdb behaviour between:
- having a .gdb_index section, and
- having a .gdb_names section, or a partial symtab, or -readnow.
Fix the inconsistency by completing implementation of
dw2_map_matching_symbols.
Tested on x86_64-linux, both with native and target board
cc-with-debug-index.
gdb/ChangeLog:
2020-05-20 Tom de Vries <tdevries@suse.de>
PR symtab/25833
* dwarf2/read.c (dw2_map_matching_symbols): Handle .gdb_index.
gdb/testsuite/ChangeLog:
2020-05-20 Tom de Vries <tdevries@suse.de>
PR symtab/25833
* gdb.base/with-mf-inc.c: New test.
* gdb.base/with-mf-main.c: New test.
* gdb.base/with-mf.exp: New file.
When running test-case gdb.base/gdb-caching-proc.exp all passes are unique,
but fails might not be.
Fix this by using with_test_prefix.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-18 Tom de Vries <tdevries@suse.de>
* gdb.base/gdb-caching-proc.exp: Use with_test_prefix.
In the following conditions:
- A target with hardware breakpoints available, and
- A target that uses software single stepping,
- An instruction at ADDRESS loops back to itself,
Now consider the following steps:
1. The user places a hardware breakpoint at ADDRESS (an instruction
that loops to itself),
2. The inferior runs and hits the breakpoint at ADDRESS,
3. The user tells GDB to 'continue'.
In #3 when the user tells GDB to continue, GDB first disables the
hardware breakpoint at ADDRESS, and then inserts a software
single-step breakpoint at ADDRESS. The original user-created
breakpoint was a hardware breakpoint, while the single-step breakpoint
will be a software breakpoint.
GDB continues and immediately hits the software single-step
breakpoint.
GDB then deletes the software single-step breakpoint by calling
delete_single_step_breakpoints, which eventually calls
delete_breakpoint, which, once the breakpoint (and its locations) are
deleted, calls update_global_location_list.
During update_global_location_list GDB spots that we have an old
location (the software single step breakpoint location) that is
inserted, but being deleted, and a location (the original hardware
breakpoint) at the same address which we are keeping, but which is not
currently inserted, GDB then calls breakpoint_locations_match on these
two locations.
Currently the locations do match, and so GDB calls swap_insertion
which swaps the "inserted" state of the two locations. The user
created hardware breakpoint is marked as inserted, while the GDB
internal software single step breakpoint is now marked as not
inserted. After this GDB returns through the call stack and leaves
delete_single_step_breakpoints.
After this GDB continues with its normal "stopping" process, as part
of this stopping process GDB removes all the breakpoints from the
target. Due to the swap it is now the user-created hardware
breakpoint that is marked as inserted, so it is this breakpoint GDB
tries to remove.
The problem is that GDB inserted the software single-step breakpoint
as a software breakpoint, but is now trying to remove the hardware
breakpoint. The problem is removing a software breakpoint is very
different to removing a hardware breakpoint, this could result is some
undetected undefined behaviour, or as in the original bug report (PR
gdb/25741), could result in the target throwing an error.
With "set breakpoint always-inserted on", we can easily reproduce this
against GDBserver. E.g.:
(gdb) hbreak main
Sending packet: $m400700,40#28...Packet received: 89e58b....
Sending packet: $m400736,1#fe...Packet received: 48
Hardware assisted breakpoint 1 at 0x400736: file threads.c, line 57.
Sending packet: $Z1,400736,1#48...Packet received: OK
Packet Z1 (hardware-breakpoint) is supported
(gdb) b main
Note: breakpoint 1 also set at pc 0x400736.
Sending packet: $m400736,1#fe...Packet received: 48
Breakpoint 2 at 0x400736: file threads.c, line 57.
(gdb) del
Delete all breakpoints? (y or n) y
Sending packet: $z0,400736,1#67...Packet received: E01
warning: Error removing breakpoint 2
This patch adds a testcase that does exactly that.
Trying to enhance GDB to handle this scenario while continuing to
avoid inserting redundant software and hardware breakpoints at the
same address turns out futile, because, given non-stop and breakpoints
always-inserted, if the user:
#1 - inserts a hw breakpoint, then
#2 - inserts a sw breakpoint at the same address, and then
#3 - removes the original hw breakpoint,
GDB would have to make sure to insert the sw breakpoint before
removing the hw breakpoint, to avoid running threads missing the
breakpoint. I.e., there's always going to be a window where a target
needs to be able to handle both sw and a hw breakpoints installed at
the same address. You can see more detailed description of that issue
here:
https://sourceware.org/pipermail/gdb-patches/2020-April/167738.html
So the fix here is to just stop considering software breakpoints and
hw breakpoints duplicates, and let GDB insert sw and hw breakpoints at
the same address.
The central change is to make breakpoint_locations_match consider the
location's type too. There are several other changes necessary to
actually make that that work correctly, however:
- We need to handle the duplicates detection better. Take a look at
the loop at the tail end of update_global_location_list. Currently,
because breakpoint locations aren't sorted by type, we can end up
with, at the same address, a sw break, then a hw break, then a sw
break, etc. The result is that that second sw break won't be
considered a duplicate of the first sw break. Seems like we already
handle that incorrectly for range breakpoints.
- The "set breakpoint auto-hw on" handling is moved out of
insert_bp_location to update_global_location_list, before the
duplicates determination.
Moving "set breakpoint auto-hw off" handling as well and downgrading
it to a warning+'disabling the location' was considered too, but in
the end discarded, because we want to error out with internal and
momentary breakpoints, like software single-step breakpoints.
Disabling such locations at update_global_location_list time would
make GDB lose control of the inferior.
- In update_breakpoint_locations, the logic of matching old locations
with new locations, in the have_ambiguous_names case, is updated to
still consider sw vs hw locations the same.
- Review all ALL_BP_LOCATIONS_AT_ADDR uses, and update those that
might need to be updated, and update comments for those that don't.
Note that that macro walks all locations at a given address, and
doesn't call breakpoint_locations_match.
The result against GDBserver (with "set breakpoint
condition-evaluation host" to avoid seeing confusing reinsertions) is:
(gdb) hbreak main
Sending packet: $m400736,1#fe...Packet received: 48
Hardware assisted breakpoint 1 at 0x400736: file main.c, line 57.
Sending packet: $Z1,400736,1#48...Packet received: OK
(gdb) b main
Note: breakpoint 1 also set at pc 0x400736.
Sending packet: $m400736,1#fe...Packet received: 48
Breakpoint 4 at 0x400736: file main.c, line 57.
Sending packet: $Z0,400736,1#47...Packet received: OK
(gdb) del 3
Sending packet: $z1,400736,1#68...Packet received: OK
gdb/ChangeLog:
2020-05-17 Pedro Alves <palves@redhat.com>
Andrew Burgess <andrew.burgess@embecosm.com>
Keno Fischer <keno@juliacomputing.com>
PR gdb/25741
* breakpoint.c (build_target_condition_list): Update comments.
(build_target_command_list): Update comments and skip matching
locations.
(insert_bp_location): Move "set breakpoint auto-hw on" handling to
a separate function. Simplify "set breakpoint auto-hw off"
handling.
(insert_breakpoints): Update comment.
(tracepoint_locations_match): New parameter. For breakpoints,
compare location types too, if the caller wants to.
(handle_automatic_hardware_breakpoints): New functions.
(bp_location_is_less_than): Also sort by location type and
hardware breakpoint length.
(update_global_location_list): Handle "set breakpoint auto-hw on"
here.
(update_breakpoint_locations): Ask breakpoint_locations_match to
ignore location types.
gdb/testsuite/ChangeLog:
2020-05-17 Pedro Alves <palves@redhat.com>
PR gdb/25741
* gdb.base/hw-sw-break-same-address.exp: New file.
This commit finally does the (small) change that started this patch
series.
It ensures that the class_alias is only used for user-defined aliases.
So, the few GDB pre-defined aliases that were using the 'class_alias'
class are now using a real help class, typically the class of
the aliased command.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* command.h (enum command_class): Improve comments, document
that class_alias is for user-defined aliases, give the class
name for each class, remove unused class_xdb.
* cli/cli-decode.c (add_com_alias): Document THECLASS intended usage.
* breakpoint.c (_initialize_breakpoint): Replace class_alias
by a precise class.
* infcmd.c (_initialize_infcmd): Likewise.
* reverse.c (_initialize_reverse): Likewise.
* stack.c (_initialize_stack): Likewise.
* symfile.c (_initialize_symfile): Likewise.
* tracepoint.c (_initialize_tracepoint): Likewise.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/alias.exp: Verify 'help aliases' shows user defined aliases.
Similarly to 'help CLASS', apropos possibly shows several
times the same help (for the command and for each of its aliases).
This patch changes 'apropos' so that the help for a command and
all its aliases is shown once.
So, apropos_cmd now skips all aliases/abbreviations, as these are printed
as part of the help of the aliased command.
When 'apropos' prints the help of a command, function 'help_cmd' now
unconditionally print the command name and its possible aliases (as we must
indicate to the user the command/aliases for which the help is printed).
When 'help somecommand' prints the help of a command, if the command is not
aliased, the command name is not printed (to avoid a useless first line), but if
it has aliases, then the command name and all its aliases are now printed.
In addition to provide to the user the choice of the best way to
type a command, it also avoids the strange behaviour that the output
of 'help somealias' does not mention somealias.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-decode.c (apropos_cmd): Produce output for aliases
when their aliased command is traversed.
(help_cmd): Add fput_command_names_styled call to
output command name and aliases when command has an alias.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/help.exp: Test apropos and help for commands
having aliases. Fixed comments not starting with an
upper-case letter or not finishing with a dot.
Currently, help CLASS possibly shows several times the same help,
as it shows it once for the command, and once for each alias.
The final objective of this patch series is to have class_alias used only
for user defined aliases, not anymore for aliases predefined by GDB.
The command 'help aliases' will then only show the user defined aliases.
So, the idea is that GDB predefined aliases will be shown together
with their aliased command.
This commit changes 'help CLASS' so that a command is shown once in the output,
with all its aliases.
This ensures:
* that the user has only to read once the same help text
* and sees the command and all its aliases in a glance, a.o. allowing
the user to choose the preferred way (e.g. the shortest one,
or the most mnemonic one) to type the command.
For example, the old output:
(gdb) help stack
...
List of commands:
backtrace -- Print backtrace of all stack frames, or innermost COUNT frames.
bt -- Print backtrace of all stack frames, or innermost COUNT frames.
...
(note that 'where' is not shown in this output)
becomes
(gdb) help stack
...
List of commands:
backtrace, where, bt -- Print backtrace of all stack frames, or innermost COUNT frames.
...
The output layout chosen is to have the command first, followed by all its
aliases separated by a comma. Note that the command and alias names are
title-styled. For sure, other layouts could be discussed, but this one is IMO
readable and compact.
The function 'help_cmd_list' can be simplified by removing the prefix argument,
as the prefixname of a command can now be retrieved in the GDB command tree
structure.
This also fixes the fact that 'help aliases' wrongly shows a long
list of (non-alias) when defining an alias for a prefix command.
For example, after:
(gdb) alias montre = show
then
(gdb) help aliases
shows hundreds of sub-commands starting with the non aliased command,
such as:
montre -- Generic command for showing things about the debugger.
show ada -- Generic command for showing Ada-specific settings.
show ada print-signatures -- Show whether the output of formal ...
....
'help_cmd_list' is also made static, as it is only used inside cli-decode.c.
Note that the 'help CLASS' is somewhat broken, in the sense that it
sometimes shows too many commands (commands not belonging to CLASS)
and sometimes shows not enough commands (not showing some commands
belonging to CLASS).
For example, 'help breakpoints' shows the command
'disable pretty-printer' and 'disable unwinder', not related to breakpoints.
On the other end, 'help stack' does not show 'disable unwinder'
while 'disable unwinder' is defined in unwinders.py as belonging to class_stack.
Fixing the missing commands is easy to do,
but fixing the excess commands is not straightforward, as many
subcommands have a class 'no_class' or 'all_class'.
Possibly, some of this might be improved/fixed in another patch series.
With this patch series, the 'abbrev flag' has as only remaining purpose
to avoid having the abbreviation alias appearing in the completion list,
so change 'help alias' accordingly.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-decode.h (help_cmd_list): Remove declaration.
* cli/cli-decode.c (help_cmd_list): Declare as static,
remove prefix argument, use bool for recurse arg, rework to show the aliases of
a command together with the command.
(fput_command_name_styled, fput_command_names_styled): New functions.
(print_help_for_command): Remove prefix arg, use bool for recurse arg, use
fput_command_name_styled.
(help_list, help_all): Update callers to remove prefix arg and use bool recurse.
* cli/cli-cmds.c (_initialize_cli_cmds): Update alias_command doc.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/alias.exp: Update help output check.
cmd_show_list function implements the 'show' command.
cmd_show_list output is inconsistent: it sometimes shows a prefix
and sometimes does not.
For example, in the below, you see that there is a prefix before
each value, except for 'enabled'.
(gdb) show style
style address background: The "address" style background color is: none
style address foreground: The "address" style foreground color is: blue
style address intensity: The "address" style display intensity is: normal
enabled: CLI output styling is enabled.
style filename background: The "filename" style background color is: none
...
There are other inconsistencies or bugs e.g. in
the below we see twice insn-number-max, once with a prefix
and once without prefix : last line, just before the value of
instruction-history-size which is itself without prefix.
(gdb) show record
record btrace bts buffer-size: The record/replay bts buffer size is 65536.
record btrace cpu: btrace cpu is 'auto'.
record btrace pt buffer-size: The record/replay pt buffer size is 16384.
record btrace replay-memory-access: Replay memory access is read-only.
record full insn-number-max: Record/replay buffer limit is 200000.
record full memory-query: Whether query if PREC cannot record memory change of next instruction is off.
record full stop-at-limit: Whether record/replay stops when record/replay buffer becomes full is on.
function-call-history-size: Number of functions to print in "record function-call-history" is 10.
insn-number-max: instruction-history-size: Number of instructions to print in "record instruction-history" is 10.
(gdb)
Also, some values are output several times due to some aliases, so avoid outputting duplicated
values by skipping all aliases.
Now that the command structure has a correct 'back-pointer' from a command
to its prefix command, we can simplify cmd_show_list by removing its prefix argument
and at the same time fix the output inconsistencies and bugs.
gdb/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-setshow.h (cmd_show_list): Remove prefix argument.
* cli/cli-decode.c (do_show_prefix_cmd): Likewise.
* command.h (cmd_show_list): Likewise.
* dwarf2/index-cache.c (show_index_cache_command): Likewise.
* cli/cli-setshow.c (cmd_show_list): Use the prefix to produce the output. Skip aliases.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/default.exp: Update output following fixes.
When an alias name starts with the name of another alias,
GDB was accepting to define the aliases in one order (short first, long after),
but refused it the other way around.
So, fix the logic to recognise an already existing alias by using
lookup_cmd_composition.
Also, this revealed a bug in lookup_cmd_composition:
when the searched command is a prefix command, lookup_cmd_composition
was not returning the fact that a command was found even if the
TEXT to parse was fully consumed.
gdb/ChangeLog
YYYY-MM-DD Philippe Waroquiers <philippe.waroquiers@skynet.be>
* cli/cli-cmds.c (alias_command): Check for an existing alias
using lookup_cmd_composition, as valid_command_p is too strict
and forbids aliases that are the prefix of an existing alias
or command.
* cli/cli-decode.c (lookup_cmd_composition): Ensure a prefix
command is properly recognised as a valid command.
gdb/testsuite/ChangeLog
2020-05-15 Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/alias.exp: Test aliases starting with a prefix of
another alias.
When running the testsuite with clang, a number of testcases fail to
build with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: control may reach end of non-void function [-Wreturn-type]
This prevents a number of testcases from executing. This commit fixes.
gdb/testsuite/ChangeLog:
* gdb.base/info-os.c (main): Add return statement.
* gdb.base/info_minsym.c (minsym_fun): Likewise.
* gdb.base/large-frame-2.c (func): Likewise.
* gdb.base/pr10179-a.c (foo1, bar1): Likewise.
* gdb.base/pr10179-b.c (foo2): Likewise.
* gdb.base/valgrind-disp-step.c (foo): Likewise.
* gdb.base/watch-cond.c (func): Likewise.
* gdb.multi/goodbye.c (verylongfun): Likewise.
* gdb.multi/hello.c (commonfun): Likewise.
* gdb.python/py-finish-breakpoint.c (call_longjmp): Likewise.
* gdb.threads/fork-plus-threads.c (thread_func): Likewise.
* gdb.threads/forking-threads-plus-breakpoint.c (thread_forks):
Likewise.
* gdb.threads/hand-call-new-thread.c (foo): Likewise.
* gdb.threads/interrupt-while-step-over.c (child_function):
Likewise.
* gdb.trace/actions-changed.c (end): Likewise.
Say we have some common tcl code that we want to include in test-cases
t1.exp and t1.exp.
We could put the common code into a file common.exp alongside the test-cases,
but that will make dejagnu treat that file as another test-case. To prevent
this, we use a suffix, currently .in, in other words we put the common code in
a file common.exp.in.
The .in suffix however is also used in autoconf, which might cause confusion.
Change the suffix from .in to .tcl.
gdb/testsuite/ChangeLog:
2020-05-15 Tom de Vries <tdevries@suse.de>
* gdb.base/align.exp.in: Rename to ...
* gdb.base/align.exp.tcl: ... this.
* gdb.base/align-c++.exp: Update.
* gdb.base/align-c.exp: Update.
* gdb.base/all-architectures.exp.in: Rename to ...
* gdb.base/all-architectures.exp: ... this.
* gdb.base/all-architectures-0.exp: Update.
* gdb.base/all-architectures-1.exp: Update.
* gdb.base/all-architectures-2.exp: Update.
* gdb.base/all-architectures-3.exp: Update.
* gdb.base/all-architectures-4.exp: Update.
* gdb.base/all-architectures-5.exp: Update.
* gdb.base/all-architectures-6.exp: Update.
* gdb.base/all-architectures-7.exp: Update.
* gdb.base/infcall-nested-structs.exp.in: Rename to ...
* gdb.base/infcall-nested-structs.exp.tcl: ... this.
* gdb.base/infcall-nested-structs-c++.exp: Update.
* gdb.base/infcall-nested-structs-c.exp: Update.
* gdb.base/info-types.exp.in: Rename to ...
* gdb.base/info-types.exp.tcl: ... this.
* gdb.base/info-types-c++.exp: Update.
* gdb.base/info-types-c.exp: Update.
* gdb.base/max-depth.exp.in: Rename to ...
* gdb.base/max-depth.exp.tcl: ... this.
* gdb.base/max-depth-c++.exp: Update.
* gdb.base/max-depth-c.exp: Update.
* gdb.cp/cpexprs.exp.in: Rename to ...
* gdb.cp/cpexprs.exp.tcl: ... this.
* gdb.cp/cpexprs-debug-types.exp: Update.
* gdb.cp/cpexprs.exp: Update.
* gdb.cp/infcall-nodebug.exp.in: Rename to ...
* gdb.cp/infcall-nodebug.exp.tcl: ... this.
* gdb.cp/infcall-nodebug-c++-d0.exp: Update.
* gdb.cp/infcall-nodebug-c++-d1.exp: Update.
* gdb.cp/infcall-nodebug-c-d0.exp: Update.
* gdb.cp/infcall-nodebug-c-d1.exp: Update.
* gdb.dwarf2/clang-debug-names.exp.in: Rename to ...
* gdb.dwarf2/clang-debug-names.exp.tcl: ... this.
* gdb.dwarf2/clang-debug-names-2.exp: Update.
* gdb.dwarf2/clang-debug-names.exp: Update.
With test-case gdb.base/align.exp and target board native-gdbserver, we run
into:
...
(gdb) file outputs/gdb.base/align/c/align^M
Reading symbols from outputs/gdb.base/align/c/align...^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break main^M
Breakpoint 1 at 0x4004ab: file outputs/gdb.base/align/c/align.c, line 838.^M
(gdb) kill^M
The program is not being run.^M
(gdb) spawn gdbserver --once localhost:2592 outputs/gdb.base/align/align^M
Process outputs/gdb.base/align/align created; pid = 6946^M
Listening on port 2592^M
target remote localhost:2592^M
Remote debugging using localhost:2592^M
warning: Mismatch between current exec-file outputs/gdb.base/align/c/align^M
and automatically determined exec-file outputs/gdb.base/align/align^M
exec-file-mismatch handling is currently "ask"^M
Load new symbol table from "outputs/gdb.base/align/align"? (y or n) Quit^M
(gdb) ERROR: test suppressed
...
Fix this by turning this and similar test-cases into regular, single
executable test-cases.
This fixes 100+ FAILs with target board native-gdbserver.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-14 Tom de Vries <tdevries@suse.de>
* gdb.base/align.exp: Split into ...
* gdb.base/align.exp.in: ...
* gdb.base/align-c++.exp: ...
* gdb.base/align-c.exp: ... these.
* gdb.base/infcall-nested-structs.exp: Split into ...
* gdb.base/infcall-nested-structs.exp.in: ...
* gdb.base/infcall-nested-structs-c++.exp: ...
* gdb.base/infcall-nested-structs-c.exp: ... these.
* gdb.base/info-types.exp: Split into ...
* gdb.base/info-types.exp.in: ...
* gdb.base/info-types-c++.exp: ...
* gdb.base/info-types-c.exp: ... these.
* gdb.base/max-depth.exp: Split into ...
* gdb.base/max-depth.exp.in: ...
* gdb.base/max-depth-c++.exp: ...
* gdb.base/max-depth-c.exp: ... these.
* gdb.cp/infcall-nodebug.exp: Split into ...
* gdb.cp/infcall-nodebug.exp.in: ...
* gdb.cp/infcall-nodebug-c++-d0.exp: ...
* gdb.cp/infcall-nodebug-c++-d1.exp: ...
* gdb.cp/infcall-nodebug-c-d0.exp: ...
* gdb.cp/infcall-nodebug-c-d1.exp: ... these.
In stop_all_threads, the thread events of the current top target are
enabled at the beginning of the function and then disabled at the end
(at scope exit time). Because there may be multiple targets whose
thread lists will be updated and whose threads are stopped,
enable/disable thread events for all targets.
This update caused a change in the annotations. In particular, a
"frames-invalid" annotation is printed one more time due to switching
the current inferior. Hence, gdb.base/annota1.exp and
gdb.cp/annota2.exp tests are also updated.
Regression-tested on X86_64 Linux using the default board file and the
native-extended-gdbserver board file.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (stop_all_threads): Enable/disable thread events of all
targets. Move a debug message denoting the end of the function
into the SCOPED_EXIT block.
gdb/testsuite/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/annota1.exp: Update the expected output.
* gdb.cp/annota2.exp: Ditto.
When running test-case gdb.base/jit-elf.exp with target board
cc-with-gdb-index, we get:
...
spawn -ignore SIGHUP gdb/contrib/cc-with-tweaks.sh -i gcc \
-fno-stack-protector src/gdb/testsuite/gdb.base/jit-elf-main.c \
-fdiagnostics-color=never -DATTACH=1 -DLOAD_ADDRESS=0x7000000 \
-DLOAD_INCREMENT=0x1000000 -g -lm \
-o outputs/gdb.base/jit-elf/jit-elf-main"-attach"^M
outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.^M
output is:
outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.^M
gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.
UNTESTED: gdb.base/jit-elf.exp: failed to compile jit-elf-main"-attach"
...
The problem is a string concat in jit-elf.exp:
...
${main_binfile}"-attach"
...
which is intended to generate string 'jit-elf-main-attach' but instead
generates string 'jit-elf-main"-attach"'.
Fix this by using "${main_binfile}-attach" instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* gdb.base/jit-elf.exp: Fix string concat.
Splits ELF related symbols into a separate jit-elf-util.h header and
enhances it with a few more.
Intention is to make adding new JIT tests possible without repeating
most of the common boilerplate.
As a test enhancement, jit-elf-main.c now calls the renamed function
after registering the jit object and ensures it returns an expected
result.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-elf-util.h: New header file.
* gdb.base/jit-elf-main.c: Use jit-elf-util.h, add a call to
the renamed JIT function to verify its result.
Replaces previous approach with patching resulting ELF binary after
loading - now that each test iteration works on a separately compiled
binary it is not necessary anymore.
Tests are still being ran without debug info to preserve original test
functionality but this change opens up the possibility to enable debug
info if needed too.
gdb/testsuite/ChangeLog:
2020-03-27 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -DFUNCTION_NAME macro
definition when compiling jit-elf-solib.co.
* gdb.base/jit-elf-main.c: Stop patching jit function name.
* gdb.base/jit-elf-solib.c: Use FUNCTION_NAME macro value as a
function name.
Removes the need to manually relocate loaded ELF binary by using a fixed
constant as both mmap base address and as a requested first segment
address supplied to the linker.
In future will enable JIT tests with a valid DWARF debug info. Current
tests still need to compile without a debug info though, because they do
a function name modification.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -Ttext-segment linker flag and
define LOAD_ADDRESS/LOAD_INCREMENT macros for the compiled binaries.
* gdb.base/jit-elf-main.c: Use LOAD_ADDRESS/LOAD_INCREMENT to
calculate the mmap address.
New utility library to be used by jit-elf tests responsible for
compiling binary artifacts. In the next commit the compilation process
will become more complicated because of extra mandatory flag - keeping
it in one place will make tests less fragile.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: New file.
* gdb.base/jit-elf.exp: Updated to use jit-elf-helpers.exp.
* gdb.base/jit-elf-so.exp: Updated to use jit-elf-helpers.exp.
Old usage: jit-elf-main lib.so 2
New usage: jit-elf-main lib.so.1 lib.so.2
Refactoring necessary to support running tests over multiple jit
binaries rather than mapping the same binary muultiple times.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-elf-main.c: Read lib list from argc/argv.
* gdb.base/jit-elf.exp: Compile N jit libraries and use the list.
* gdb.base/jit-elf-so.exp: Ditto.
When running gdb.base/jit-so.exp, we see duplicate test names:
$ grep PASS testsuite/gdb.sum | sort | uniq -c | sort -n
...
2 PASS: gdb.base/jit-so.exp: one_jit_test-1: info function jit_function
2 PASS: gdb.base/jit-so.exp: one_jit_test-2: info function jit_function
Give an explicit name to one test to avoid this.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp (one_jit_test): Change test name.
When running test-case gdb.base/watchpoint-reuse-slot.exp with gcc-8 instead
of gcc-7, we have:
...
(gdb) PASS: $conf: watch *(buf.byte + 0 + 0)@1
stepi^M
-0x00000000004004b9 34 for (i = 0; i < 100000; i++);^M
+34 for (i = 0; i < 100000; i++);^M
-(gdb) PASS: $conf: stepi advanced
+(gdb) FAIL: $conf: stepi advanced
...
where $conf is "gdb.base/watchpoint-reuse-slot.exp: hw-watch: always-inserted
off: watch x watch: : width 1, iter 0: base + 0".
This is due to the fact that gcc-8 generates more precise line info, making
the instruction at 0x4004b9 a "recommended breakpoint location", such that gdb
no longer prints the instruction address.
Fix this by getting the instruction address by printing $pc.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* gdb.base/watchpoint-reuse-slot.exp (stepi): Print $pc to get current
address.
I noticed this code in gdb.base/watchpoint-reuse-slot.exp, proc stepi:
...
gdb_test_multiple "stepi" $test {
-re "($hex).*[string_to_regexp $srcline]\r\n$gdb_prompt $" {
set addr $expect_out(1,string)
if {$addr != $cur_addr} {
pass $test
} else {
fail $test
}
set cur_addr addr
}
}
...
The variable cur_addr is documented as:
...
# The address the program is stopped at currently.
set cur_addr ""
...
but in the gdb_test_multiple clause we assign the string "addr" to cur_addr,
while $addr contains the current address.
Fix this by assigning $addr instead "addr".
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* gdb.base/watchpoint-reuse-slot.exp: Fix incorrect assignment.
When running gdb.base/store.exp with gcc-10 instead of gcc-9, we have:
...
(gdb) PASS: gdb.base/store.exp: continue to wack_double
print l^M
-$22 = <optimized out>^M
+$22 = -1^M
-(gdb) UNSUPPORTED: gdb.base/store.exp: var double l; print old l, expecting -1
-(gdb) PASS: gdb.base/store.exp: var double l; print old l, expecting -1
+print r^M
+$23 = <optimized out>^M
+(gdb) FAIL: gdb.base/store.exp: var double l; print old r, expecting -2
...
With gcc-9, there's no location info for both l and r, but with gcc-10,
there's location info for l, but not r.
The test-case only checks for location info availability of l, and then
assumes location info for r is also available.
Fix this by allowing missing location info for r.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* gdb.base/store.exp (check_set, up_set): Allowing missing location
info for r.
When running test-case gdb.base/shlib-call.exp with gcc-8 instead of gcc-7, we
have:
...
(gdb) step^M
-main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:42^M
-42 g = mainshr1(g);^M
-(gdb) PASS: gdb.base/shlib-call.exp: step out of shr2 epilogue to main
+main () at /data/gdb_versions/devel/src/gdb/testsuite/gdb.base/shmain.c:41^M
+41 g = shr2(g);^M
+(gdb) FAIL: gdb.base/shlib-call.exp: step out of shr2 epilogue to main
...
This is due to the fact that gcc-8 generates more precise line info, making
the instruction after the call to shr2 at 0x4008f1:
...
4008e4: 8b 05 aa 07 20 00 mov 0x2007aa(%rip),%eax # 601094 <g>
4008ea: 89 c7 mov %eax,%edi
4008ec: e8 1f fe ff ff callq 400710 <shr2@plt>
4008f1: 89 05 9d 07 20 00 mov %eax,0x20079d(%rip) # 601094 <g>
...
a "recommended breakpoint location":
...
[0x00000287] Special opcode 187: advance Address by 13 to 0x4008f1 and \
Line by 0 to 41
...
so when stepping out of shr2, gdb steps back onto line 41, the line containing
the call to shr2.
Fix this by detecting this situation and adding an extra step to reach
line 42.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-06 Tom de Vries <tdevries@suse.de>
* gdb.base/shlib-call.exp: Add extra step to reach shmain.c:42, if
necessary.
Pedro Alves
Nick Alcock
Philippe Waroquiers
Sandra Loosemore
Simon Marchi
Tankut Baris Aktemur
Tom Tromey
Keith Seitz
Tom de Vries
Simon Marchi
Gary Benson
Luis Machado
Andrew Burgess
Mihails Strasuns
Mihails Strasuns via Gdb-patches