| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Replace the "SPECIAL_expr" comment with either "DW_FORM_block" or
"DW_FORM_exprloc" in the abbrev.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::_handle_attribute): Handle SPECIAL_expr
specially, set attr_form_comment to the actual FORM string used.
|
|
Since DWARF version 4 expressions are represented by DW_FORM_exprloc
instead of a block form. Support this in the testsuite Dwarf Assembler
by setting the SPECIAL_expr form once we know the CU version.
This doesn't change any testsuite results, it just makes the produced
DWARF valid. gdb also accepts expressions in block form for DWARF
version 4 and above, but this is technically incorrect.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::_read_constants): Don't set
_constants(SPECIAL_expr) here, but set it...
(Dwarf::cu): ...here based on _cu_version.
|
|
When running test-case gdb.base/info-shared.exp, I see in gdb.log:
...
Executing on host: \
gcc ... -fPIC -fpic -c -o info-shared-solib1.c.o info-shared-solib1.c
...
The -fPIC comes from the test-case:
...
if { [gdb_compile_shlib $srcfile_lib1 $binfile_lib1 \
[list additional_flags=-fPIC]] != "" } {
...
but the -fpic, which overrides the -fPIC comes from gdb_compile_shlib.
The proc gdb_compile_shlib adds the -fpic or similar dependent on platform
and compiler. However, in some cases it doesn't add anything, which is
probably why all those test-case pass -fPIC.
Fix this by removing -fPIC from all the calls to gdb_compile_shlib, and
ensuring that gdb_compile_shlib takes care of adding it, if required.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-14 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_compile_shlib): Make sure it's not necessary to
pass -fPIC.
* gdb.ada/catch_ex_std.exp: Don't pass -fPIC to gdb_compile_shlib.
* gdb.base/break-probes.exp: Same.
* gdb.base/ctxobj.exp: Same.
* gdb.base/dso2dso.exp: Same.
* gdb.base/global-var-nested-by-dso.exp: Same.
* gdb.base/info-shared.exp: Same.
* gdb.base/jit-reader-simple.exp: Same.
* gdb.base/print-file-var.exp: Same.
* gdb.base/skip-solib.exp: Same.
* gdb.btrace/dlopen.exp: Same.
|
|
When running test-case gdb.base/gnu-debugdata.exp on SLE-11, I run into:
...
FAIL: gdb.base/gnu-debugdata.exp: xz
...
The fact that xz is not installed does not mean there's a fail, merely that
the test is unsupported.
Fix this by detecting the "spawn failed" reply in run_on_host and issuing
UNSUPPORTED instead.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-12-14 Tom de Vries <tdevries@suse.de>
PR testsuite/26963
* lib/gdb.exp (run_on_host): Declare test unsupported if spawn fails.
|
|
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.
|
|
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
|
|
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
|
|
Running:
make check TESTS="gdb.mi/mi-nonstop-exit.exp" RUNTESTFLAGS="--target_board=native-extended-gdbserver"
We get:
Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.mi/mi-nonstop-exit.exp ...
ERROR: Unable to start target
=== gdb Summary ===
# of expected passes 2
The root cause of the problem is the typical "we try to enable non-stop
after having connected to gdbserver". This is because with the
native-extended-gdbserver board, GDB connects to GDBserver as soon as
it's started. It's too late then to do "set non-stop 1" or "-gdb-set
non-stop 1". This is fixed by the following patch.
More worrying is that the error is not reported (except for the
printout). From the testsuite point of view, everything went fine.
runtest exits with status 0.
This is because mi_run_cmd_full uses perror. perror just prints that
ERROR and makes it so the next test becomes UNRESOLVED. However,
there's no next test, because we just return early, seeing that we
couldn't run.
Change mi_run_cmd_full to call unresolved directly instead. This
ensures that the failure is recorded.
This is the results diff when running the gdb.mi/*.exp tests:
# of unexpected failures 34
# of expected failures 8
# of known failures 13
-# of unresolved testcases 4
+# of unresolved testcases 10
# of unsupported tests 1
# of duplicate test names 34
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_run_cmd_full): Use unresovled instead
of perror.
Change-Id: Ib0f214c0127fbe73f2033c6c29d678e025690220
|
|
Similar to my recent fix for gdb_file_cmd, mi_gdb_file_cmd also runs
into problems when GCC has created foo.exe given "-o foo".
Apply exactly the same fix there as in gdb_file_cmd. This allows many
more tests to succeed for Windows target that previously fell over.
2020-11-18 Joseph Myers <joseph@codesourcery.com>
* lib/mi-support.exp (mi_gdb_file_cmd): Check for case where
$arg.exe exists but $arg does not.
|
|
GCC for Windows target produces executables called foo.exe when given
"-o foo". (More specifically, it's done that for native compilers for
a long time, and for cross compilers to Windows target since GCC
commit 5bc86b599054f494ec0a45e49b82749320eaa9c4, in GCC 8 and later.)
This causes problems for many GDB tests expecting a program to have
the exact file name passed to -o.
Fix this by checking for the case where only the .exe exists in
gdb_file_cmd and adjusting the name passed to the file command
accordingly. There may well be other places with this issue in the
GDB testsuite, but this fix allows many tests to succeed that
previously fell over.
2020-11-12 Joseph Myers <joseph@codesourcery.com>
* lib/gdb.exp (gdb_file_cmd): Check for case where $arg.exe exists
but $arg does not.
|
|
In commit:
commit 6d81691950f8c4be4a49a85a672255c140e82468
CommitDate: Sat Sep 19 09:44:58 2020 +0100
gdb/fortran: Move Fortran expression handling into f-lang.c
A bug was introduced that broke GDB's ability to perform debug dumps
of expressions containing function calls. For example this would no
longer work:
(gdb) set debug expression 1
(gdb) print call_me (&val)
Dump of expression @ 0x4eced60, before conversion to prefix form:
Language c, 12 elements, 16 bytes each.
Index Opcode Hex Value String Value
0 OP_VAR_VALUE 40 (...............
1 OP_M2_STRING 79862864 P...............
2 unknown opcode: 224 79862240 ................
3 OP_VAR_VALUE 40 (...............
4 OP_VAR_VALUE 40 (...............
5 OP_RUST_ARRAY 79861600 `...............
6 UNOP_PREDECREMENT 79861312 @...............
7 OP_VAR_VALUE 40 (...............
8 UNOP_ADDR 61 =...............
9 OP_FUNCALL 46 ................
10 BINOP_ADD 1 ................
11 OP_FUNCALL 46 ................
Dump of expression @ 0x4eced60, after conversion to prefix form:
Expression: `call_me (&main::val, VAL(Aborted (core dumped)
The situation was even worse for Fortran function calls, or array
indexes, which both make use of the same expression opcode.
The problem was that in a couple of places the index into the
expression array was handled incorrectly causing GDB to interpret
elements incorrectly. These issues are fixed in this commit.
There are already some tests to check GDB when 'set debug expression
1' is set, these can be found in gdb.*/debug-expr.exp. Unfortunately
the cases above were not covered.
In this commit I have cleaned up all of the debug-expr.exp files a
little, there was a helper function that had clearly been copied into
each file, this is now moved into lib/gdb.exp.
I've added a gdb.fortran/debug-expr.exp test file, and extended
gdb.base/debug-expr.exp to cover the function call case.
gdb/ChangeLog:
* expprint.c (print_subexp_funcall): Increment expression position
after reading argument count.
* f-lang.c (print_subexp_f): Skip over opcode before calling
common function.
(dump_subexp_body_f): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/debug-expr.c: Add extra function to allow for an
additional test.
* gdb.base/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr. Add an extra test.
* gdb.cp/debug-expr.exp (test_debug_expr): Delete, replace calls
to this proc with gdb_test_debug_expr, give the tests names
* gdb.dlang/debug-expr.exp (test_debug_expr): Delete, replace
calls to this proc with gdb_test_debug_expr, give the tests names
* gdb.fortran/debug-expr.exp: New file.
* gdb.fortran/debug-expr.f90: New file.
* lib/gdb.exp (gdb_test_debug_expr): New proc.
|
|
When creating a .debug_ranges section using the testsuite's DWARF
assembler, it currently looks like this:
ranges {
sequence {
{base ...}
{range ...}
{range ...}
}
}
The sub-tree of sequence is manually traversed as a list of lists. I
think it would be nicer if `base` and `range` where procedure, just like
the other levels:
ranges {
sequence {
base ...
range ...
range ...
}
}
That makes the implementation more robust, and the usage a bit nicer
(less special characters). It also allows having comments in between
the range list entries:
ranges {
sequence {
base ...
range ...
# Hello world.
range ...
}
}
... which doesn't work with the current approach.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (ranges): Handle "base" and "range" as
proceduresu.
* gdb.dwarf/dw2-bad-elf.exp: Adjust.
* gdb.dwarf2/dw2-inline-many-frames.exp: Adjust.
* gdb.dwarf2/dw2-inline-stepping.exp: Adjust.
* gdb.dwarf2/dw2-ranges-base.exp: Adjust.
* gdb.dwarf2/dw2-ranges-func.exp: Adjust.
* gdb.dwarf2/dw2-ranges-overlap.exp: Adjust.
* gdb.dwarf2/dw2-ranges-psym.exp: Adjust.
* gdb.dwarf2/enqueued-cu-base-addr.exp: Adjust.
Change-Id: I0b2af480faff54d0fd4214e0cc8d042d9583a865
|
|
The abbreviations table for a single compilation unit has two types of
terminators:
- a ".byte 0" pair denoting the end of an attribute list
- a single ".byte 0" denoting the end of the table
However, at the end of the .debug_abbrev section in dw2-line-number-zero-dw.S,
we have four ".byte 0" entries:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
.byte 0x0 /* Terminator */
...
The first two are the attribute list terminator, the third is the end-of-table
terminator, and the last is superfluous/incorrect.
Fix this by emitting instead:
...
.uleb128 0x12 /* DW_AT_high_pc */
.uleb128 0x01 /* DW_FORM_addr */
.byte 0x0 /* DW_AT - Terminator */
.byte 0x0 /* DW_FORM - Terminator */
.byte 0x0 /* Abbrev end - Terminator */
...
where the last comment resembles the comment for other abbreviation codes:
...
.section .debug_abbrev
.Labbrev1_begin:
.uleb128 2 /* Abbrev start */
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-11-03 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::_handle_DW_TAG): Improve attribute list
terminator comments.
(Dwarf::cu, Dwarf::tu): Remove superfluous abbreviation table
terminator.
|
|
In commits 221db974e653659edb280787af1b3efdd1615083 and
68d654afdfcff840ebb3ae432ed72dca0521d670, these patches:
2020-06-24 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
compiling C++ programs.
2020-09-25 Gary Benson <gbenson@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" earlier, and only
for .c files.
attempted to fix problems with testcases that compile .c files
using the C++ compiler. These patches cause gdb_compile to add
"-x c++" to the compiler options when using Clang. This fix does
not work for gdb.base/print-file-var.exp, however, which attempts
to compile a .c input file to an executable linked with shared
libraries: the resulting command caused the compiler to attempt
to parse the .so files as C++. This commit causes gdb_compile
to reject this combination of options.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Inhibit passing "-x c++"
for .c files compiled as C++ with Clang if any shared
libraries are specified.
|
|
Clang fails to compile a number of files with the following warning:
unknown attribute 'noclone' ignored [-Wunknown-attributes]. This
commit adds a new header, lib/noclone.h, which defines the macro
ATTRIBUTE_NOCLONE accordingly, and updates the relevant testcases
to use it.
gdb/testsuite/ChangeLog:
* lib/attributes.h: New header.
* gdb.base/backtrace.c: Include the above. Replace
__attribute__(noclone)) with ATTRIBUTE_NOCLONE.
* gdb.base/infcall-nested-structs.c: Likewise.
* gdb.base/vla-optimized-out.c: Likewise.
|
|
With test-case gdb.rust/traits.exp and target board readnow we get:
...
FAIL: gdb.rust/traits.exp: print *td
FAIL: gdb.rust/traits.exp: print *tu
...
Mark these FAILs as KFAILs.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-28 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (readnow): Handle arg.
* gdb.rust/traits.exp: Add KFAILs for -readnow.
|
|
When running test-case gdb.cp/nsalias.exp with target board readnow, we get:
...
FAIL: gdb.cp/nsalias.exp: complaint for too many recursively imported \
declarations
...
The complaint is not detected, because:
- the complaint is triggered during the file command instead of during
"print N100::x"
- the "set complaints 1" is not effective because it's issued
after the file command
Fix the FAIL by setting the complaints limit earlier, and detecting the
complaint also during the file command.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-28 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_file_cmd): Set gdb_file_cmd_msg.
* gdb.cp/nsalias.exp: Set complaints limit before file cmd. Expect
complaint during file command for -readnow.
|
|
The previous patch made it possible to define a condition if it's
valid at some locations. If the condition is invalid at all of the
locations, it's rejected. However, there may be cases where the user
knows the condition *will* be valid at a location in the future,
e.g. due to a shared library load.
To make it possible that such condition can be defined, this patch
adds an optional '-force' flag to the 'condition' command, and,
respectively, a '-force-condition' flag to the 'break'command. When
the force flag is passed, the condition is not rejected even when it
is invalid for all the current locations (note that all the locations
would be internally disabled in this case).
For instance:
(gdb) break test.c:5
Breakpoint 1 at 0x1155: file test.c, line 5.
(gdb) cond 1 foo == 42
No symbol "foo" in current context.
Defining the condition was not possible because 'foo' is not
available. The user can override this behavior with the '-force'
flag:
(gdb) cond -force 1 foo == 42
warning: failed to validate condition at location 1.1, disabling:
No symbol "foo" in current context.
(gdb) info breakpoints
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
stop only if foo == 42
1.1 N 0x0000000000001155 in main at test.c:5
Now the condition is accepted, but the location is automatically
disabled. If a future location has a context in which 'foo' is
available, that location would be enabled.
For the 'break' command, -force-condition has the same result:
(gdb) break test.c:5 -force-condition if foo == 42
warning: failed to validate condition at location 0x1169, disabling:
No symbol "foo" in current context.
Breakpoint 1 at 0x1169: file test.c, line 5.
gdb/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* breakpoint.h (set_breakpoint_condition): Add a new bool parameter.
* breakpoint.c: Update the help text of the 'condition' and 'break'
commands.
(set_breakpoint_condition): Take a new bool parameter
to control whether condition definition should be forced even when
the condition expression is invalid in all of the current locations.
(condition_command): Update the call to 'set_breakpoint_condition'.
(find_condition_and_thread): Take the "-force-condition" flag into
account.
* linespec.c (linespec_keywords): Add "-force-condition" as an
element.
(FORCE_KEYWORD_INDEX): New #define.
(linespec_lexer_lex_keyword): Update to consider "-force-condition"
as a keyword.
* ada-lang.c (create_ada_exception_catchpoint): Ditto.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_condition_x): Ditto.
* python/py-breakpoint.c (bppy_set_condition): Ditto.
* NEWS: Mention the changes to the 'break' and 'condition' commands.
gdb/testsuite/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/condbreak-multi-context.exp: Expand to test forcing
the condition.
* gdb.linespec/cpcompletion.exp: Update to consider the
'-force-condition' keyword.
* gdb.linespec/explicit.exp: Ditto.
* lib/completion-support.exp: Ditto.
gdb/doc/ChangeLog:
2020-10-27 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.texinfo (Set Breaks): Document the '-force-condition' flag
of the 'break'command.
* gdb.texinfo (Conditions): Document the '-force' flag of the
'condition' command.
|
|
I noticed that the test suite command logging would create a file like
"gdb.cmd.-1". I tracked this down to a substraction in
standard_output_file_with_gdb_instance.
Then, I saw that the .in file was not created for MI. This is fixed
by adding a call to default_mi_gdb_start.
Finally, commands might not end up in the .in file in some cases. For
me this happened because the test took a long time, so I got impatient
and killed it. Flushing the file after each write seemed like a good
thing to do here.
gdb/testsuite/ChangeLog
2020-10-26 Tom Tromey <tom@tromey.com>
* lib/mi-support.exp (default_mi_gdb_start): Call
gdb_stdin_log_init.
* lib/gdb.exp (standard_output_file_with_gdb_instance): Don't
subtract one from gdb_instances.
(gdb_stdin_log_write): Flush in_file.
|
|
When running test-case gdb.base/corefile.exp with target board readnow, we run
into:
...
Reading symbols from outputs/gdb.base/corefile/corefile...^M
Expanding full symbols from outputs/gdb.base/corefile/corefile...^M
[New LWP 2293]^M
Core was generated by `outputs/gdb.base/corefile/co'.^M
Program terminated with signal SIGABRT, Aborted.^M
--Type <RET> for more, q to quit, c to continue without paging--\
FAIL: gdb.base/corefile.exp: (timeout) starting with -core
...
In commit bd447abb24 "Make gdb.base/corefile.exp work on terminals with few
rows", pagination (in the same test-case) is prevented using:
...
set stty_init "rows 25 cols 80"
...
but this doesn't work in our case because using -readnow adds an extra line
"Expanding full symbols".
The test passes when increasing rows to 26. However, increasing the rows by
some n only fixes the problem for n lines, and things will break again if
somehow we end up with n + 1 lines.
Instead, fix this by setting heigth and width in INTERNAL_GDBFLAGS. This
solution was not chosen in commit bd447abb24 because it doesn't handle
pagination due to the introduction text. But it does handle the pagination
due to the extra "Expanding full symbols", and any other line printed during
and after file loading.
Tested on x86_64-linux, with and without readnow.
With -readnow, fixes timeout FAILs in gdb.base/corefile.exp and
gdb.base/reread-readsym.exp.
gdb/testsuite/ChangeLog:
2020-10-26 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (INTERNAL_GDBFLAGS): Set heigth and width.
|
|
The only possible form for a DW_AT_low_pc attribute is DW_FORM_addr.
When specifying in dwarf assembly a low_pc attribute without explicit form:
...
{low_pc {main_label - 4}}
...
the resulting attribute uses DW_FORM_string, which is misinterpreted by gdb
when reading it as:
...
cu->base_address = attr->as_address ();
...
Stop using DW_FORM_string as default form. Instead, use a default form based
on the attribute name, if possible and unambiguous. Otherwise, error out.
F.i.:
- for DW_AT_low_pc we use DW_FORM_addr.
- For DW_AT_high_pc, we don't specify a default form because it could be
either address or constant class.
- For DW_AT_name, we use DW_FORM_string. While we could encode with
DW_FORM_strp instead, DW_FORM_string is always ok.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-23 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::_guess_form): Return "" by default instead of
DW_FORM_string.
(Dwarf::_default_form): New proc.
(Dwarf::_handle_DW_TAG): Use _default_form. Error out if no form was
guessed.
|
|
There's a common occurance in dwarf assembly test-cases, where a file test.exp
contains:
...
standard_testfile test.c test-dw.S
...
The "test.c" arg can be abbreviated to ".c".
Make standard_testfile treat args with "-" prefix the same as with "." prefix,
such that we can write:
...
standard_testfile .c -dw.S
...
and apply this in gdb.dwarf2/*.exp.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-17 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (standard_testfile): Also treat args starting with '-'
as suffix.
* gdb.dwarf2/atomic.c: Rename to ...
* gdb.dwarf2/atomic-type.c: ... this.
* gdb.dwarf2/dw2-ranges2.c: Rename to ...
* gdb.dwarf2/dw2-ranges-2.c: ... this.
* gdb.dwarf2/dw2-ranges3.c: Rename to ...
* gdb.dwarf2/dw2-ranges-3.c: ... this.
* gdb.dwarf2/fission-mix2.c: Rename to ...
* gdb.dwarf2/fission-mix-2.c: ... this.
* gdb.dwarf2/ada-linkage-name.exp: Use more suffix args for
standard_testfile.
* gdb.dwarf2/ada-valprint-error.exp: Same.
* gdb.dwarf2/arr-stride.exp: Same.
* gdb.dwarf2/arr-subrange.exp: Same.
* gdb.dwarf2/atomic-type.exp: Same.
* gdb.dwarf2/bad-regnum.exp: Same.
* gdb.dwarf2/break-inline-psymtab.exp: Same.
* gdb.dwarf2/clang-debug-names-2.exp: Same.
* gdb.dwarf2/clang-debug-names.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/corrupt.exp: Same.
* gdb.dwarf2/count.exp: Same.
* gdb.dwarf2/cpp-linkage-name.exp: Same.
* gdb.dwarf2/data-loc.exp: Same.
* gdb.dwarf2/dw2-align.exp: Same.
* gdb.dwarf2/dw2-bad-elf.exp: Same.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same.
* gdb.dwarf2/dw2-bad-unresolved.exp: Same.
* gdb.dwarf2/dw2-case-insensitive.exp: Same.
* gdb.dwarf2/dw2-cp-infcall-ref-static.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-inline-many-frames.exp: Same.
* gdb.dwarf2/dw2-inline-param.exp: Same.
* gdb.dwarf2/dw2-inline-small-func.exp: Same.
* gdb.dwarf2/dw2-inline-stepping.exp: Same.
* gdb.dwarf2/dw2-is-stmt-2.exp: Same.
* gdb.dwarf2/dw2-is-stmt.exp: Same.
* gdb.dwarf2/dw2-line-number-zero.exp: Same.
* gdb.dwarf2/dw2-namespaceless-anonymous.exp: Same.
* gdb.dwarf2/dw2-opt-structptr.exp: Same.
* gdb.dwarf2/dw2-param-error.exp: Same.
* gdb.dwarf2/dw2-ranges-base.exp: Same.
* gdb.dwarf2/dw2-ranges.exp: Same.
* gdb.dwarf2/dw2-unusual-field-names.exp: Same.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: Same.
* gdb.dwarf2/dw4-sig-types.exp: Same.
* gdb.dwarf2/dynarr-ptr.exp: Same.
* gdb.dwarf2/enum-type.exp: Same.
* gdb.dwarf2/fission-mix.exp: Same.
* gdb.dwarf2/formdata16.exp: Same.
* gdb.dwarf2/implptrconst.exp: Same.
* gdb.dwarf2/implptrpiece.exp: Same.
* gdb.dwarf2/info-locals-optimized-out.exp: Same.
* gdb.dwarf2/main-subprogram.exp: Same.
* gdb.dwarf2/method-ptr.exp: Same.
* gdb.dwarf2/missing-sig-type.exp: Same.
* gdb.dwarf2/nonvar-access.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
* gdb.dwarf2/shortpiece.exp: Same.
* gdb.dwarf2/staticvirtual.exp: Same.
* gdb.dwarf2/subrange.exp: Same.
* gdb.dwarf2/symtab-producer.exp: Same.
* gdb.dwarf2/typedef-void-finish.exp: Same.
* gdb.dwarf2/var-access.exp: Same.
* gdb.dwarf2/variant.exp: Same.
* gdb.dwarf2/void-type.exp: Same.
* gdb.dwarf2/dw2-ranges-psym.exp: Same. Use main.c instead of
dw2-ranges-main.c.
* gdb.dwarf2/dw2-ranges-main.c: Remove.
|
|
Commit 5b7d00507b adds a mention at gdb_breakpoint of a supported argument
"passfail". There's no corresponding argument handling though.
Remove the mention of the "passfail" argument.
gdb/testsuite/ChangeLog:
2020-10-16 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_breakpoint): Remove mention of "passfail".
|
|
I noticed that an abort when setting a breakpoint does not result in more
than:
...
(gdb) break 27^M
FAIL: gdb.a/b.exp: setting breakpoint at 27 (eof)
...
Handle this more verbosely, as is done in gdb_test_multiple, such that we have
instead:
...
(gdb) break 27^M
ERROR: GDB process no longer exists
GDB process exited with wait status 29309 exp9 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.a/b.exp: setting breakpoint at 27 (eof)
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-10-16 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_breakpoint): Handle eof as in gdb_test_multiple.
|
|
Since we now have mi_runto_main which is like runto_main, eliminate
mi_run_to_main, in favor of a new MI clean_restart counterpart --
mi_clean_restart -- and mi_runto_main.
This makes MI testcases look a bit more like CLI testcases.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_clean_restart): New.
(mi_run_to_main): Delete.
All callers adjust to use mi_clean_restart / mi_runto_main.
Change-Id: I34920bab4fea1f23fb752928c2969c1f6ad714b6
|
|
Similar to the previous patch, but this time add "-q" to tests that do
"break main", "list main", etc. explicitly.
gdb/testsuite/ChangeLog:
* config/monitor.exp: Use "list -q".
* gdb.arch/gdb1558.exp: Use "break -q".
* gdb.arch/i386-permbkpt.exp: Use "break -q".
* gdb.arch/i386-prologue-skip-cf-protection.exp: Use "break -q".
* gdb.base/break.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/commands.exp: Use "break -q".
* gdb.base/condbreak.exp: Use "break -q".
* gdb.base/ctf-ptype.exp: Use "list -q".
* gdb.base/define.exp: Use "break -q".
* gdb.base/del.exp: Use "break -q".
* gdb.base/fullname.exp: Use "break -q".
* gdb.base/hbreak-in-shr-unsupported.exp: Use "hbreak -q".
* gdb.base/hbreak-unmapped.exp: Use "hbreak -q".
* gdb.base/hbreak2.exp: Use "hbreak -q" and "list -q".
* gdb.base/hw-sw-break-same-address.exp: Use "break -q" and
"hbreak -q".
* gdb.base/included.exp: Use "list -q".
* gdb.base/label.exp: Use "break -q".
* gdb.base/lineinc.exp: Use "break -q".
* gdb.base/list.exp: Use "list -q".
* gdb.base/macscp.exp: Use "list -q".
* gdb.base/pending.exp: Use "break -q".
* gdb.base/prologue-include.exp: Use "break -q".
* gdb.base/ptype.exp: Use "list -q".
* gdb.base/sepdebug.exp: Use "break -q", "list -q" and "tbreak -q".
* gdb.base/server-del-break.exp: Use "break -q".
* gdb.base/style.exp: Use "break -q".
* gdb.base/symbol-without-target_section.exp: Use "list -q".
* gdb.base/watchpoint-reuse-slot.exp: Use "hbreak -q".
* gdb.cp/exception.exp: Use "tbreak -q".
* gdb.dwarf2/dw2-error.exp: Use "break -q".
* gdb.dwarf2/fission-mix.exp: Use "break -q".
* gdb.dwarf2/fission-reread.exp: Use "break -q".
* gdb.dwarf2/pr13961.exp: Use "break -q".
* gdb.linespec/explicit.exp: Use "list -q".
* gdb.linespec/linespec.exp: Use "break -q".
* gdb.mi/mi-simplerun.exp: Use "--qualified".
* gdb.python/py-mi-objfile-gdb.py: Use "list -q".
* gdb.server/bkpt-other-inferior.exp: Use "break -q".
* gdb.server/connect-without-multi-process.exp: Use "break -q".
* gdb.trace/change-loc.exp: Use "break -q".
* gdb.trace/pending.exp: Use "break -q".
* gdb.tui/basic.exp: Use "list -q".
* gdb.tui/list-before.exp: Use "list -q".
* gdb.tui/list.exp: Use "list -q".
* lib/gdb.exp (gdb_has_argv0): Use "break -q".
Change-Id: Iab9408e90ed71cbb111cd737d2d81b5ba8adb108
|
|
In some runtimes, there may be a "main" function in some class or
namespace. The breakpoint created by runto_main may therefore have
unexpected locations on some other functions than the actual main.
These breakpoint locations can unexpectedly get hit during tests and
lead to failures.
I saw this while playing with AMD's ROCm toolchain -- I wrote a board
file to run the testsuite against device kernels. There, the runtime
calls a "main" function before the device kernel code is reached:
Thread 4 "bit_extract" hit Breakpoint 1, 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
(gdb) bt
#0 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
#1 0x00007ffeea2257a5 in lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#2 0x00007ffeea1bc374 in COMGR::linkWithLLD(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#3 0x00007ffeea1bfb09 in COMGR::InProcessDriver::execute(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1
#4 0x00007ffeea1c4da9 in COMGR::AMDGPUCompiler::linkToExecutable() () from /opt/rocm/lib/libamd_comgr.so.1
#5 0x00007ffeea1fde20 in dispatchCompilerAction(amd_comgr_action_kind_s, COMGR::DataAction*, COMGR::DataSet*, COMGR::DataSet*, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1
#6 0x00007ffeea203a87 in amd_comgr_do_action () from /opt/rocm/lib/libamd_comgr.so.1
...
To avoid that, pass "qualified" to runto, in runto_main, so that
gdb_breakpoint ends up creating a breakpoint with -qualified. This
avoids creating breakpoints locations for other unrelated "main"
functions.
Note: I first tried making runto itself use "-qualified", but that
caused regressions in the gdb.ada/ tests, which use runto without
specifying the whole fully-qualified function name (i.e., without the
package). So I end up restricting the -qualified to
runto_main/mi_runto_main.
The gdb.base/ui-redirect.exp change is necessary because that testcase
is looking at what "save breakpoint" generates.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect "break -qualified main" in
saved breakpoints file.
* gdb.guile/scm-breakpoint.exp: Expect "-qualified main" when
inspecting breakpoint list.
* lib/gdb.exp (runto_main): Add "qualified" to options.
* lib/mi-support.exp (mi_runto_helper): Add 'qualified' parameter,
and handle it.
(mi_runto_main): Pass 1 as qualified argument.
Change-Id: I51468359ab0a518f05f7c0394c97f7e33b45fe69
|
|
This adds an mi_runto_main routine, very much like the runto_main CLI
counterpart.
Note there's already a mi_run_to_main (extra underscore in "run_to"),
but unlike its intro comment says, that does more than the CLI's
runto_main -- it also starts GDB. I would like to eliminate that
other one by introducing a mi_clean_restart function instead. That is
done later in the series.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_runto_main): New proc.
(mi_run_to_main): Use it.
* gdb.mi/mi-catch-cpp-exceptions.exp: Likewise.
* gdb.mi/mi-var-cmd.exp: Likewise.
* gdb.mi/mi-var-invalidate.exp: Likewise.
* mi-var-list-children-invalid-grandchild.exp: Likewise.
* gdb.mi/mi2-amd64-entry-value.exp: Likewise.
* gdb.mi/new-ui-mi-sync.exp: Likewise.
* gdb.mi/user-selected-context-sync.exp: Likewise.
* gdb.opt/inline-cmds.exp: Likewise.
* gdb.python/py-framefilter-mi.exp: Likewise.
* gdb.python/py-mi.exp: Likewise.
Change-Id: I2e49ca7b0b61cea57c1202e5dfa32417e6a4403d
|
|
In commit 221db974e653659edb280787af1b3efdd1615083, this patch:
2020-06-24 Pedro Alves <palves@redhat.com>
* lib/gdb.exp (gdb_compile): Pass "-x c++" explicitly when
compiling C++ programs.
attempted to fix problems with testcases that compile .c files
with the C++ compiler. They pass the "c++" option to gdb_compile,
resulting in the following error when using Clang:
gdb compile failed, clang-10: warning: treating 'c' input as 'c++'
when in C++ mode, this behavior is deprecated [-Wdeprecated]
This fix did not work for gdb.base/infcall-nested-structs-c++.exp,
however: the "-x c++" appeared in the compiler's commandline after
the .c file, so the option was not enabled for that file.
The previous files fixed all used build_executable_from_specs, which
compiles and links in separate steps, using gdb_compile: the compile
step passes $type=object to gdb_compile, while the link step passes
$type=executable.
gdb.base/infcall-nested-structs-c++.exp uses gdb_compile directly
instead, and it passes $type=executable to compile and link all in
one step. Pedro found that DejaGnu's default_target_compile adds
the sources at the end when $type=object, but at the beginning when
$type=executable:
# This is obscure: we put SOURCES at the end when building an
# object, because otherwise, in some situations, libtool will
# become confused about the name of the actual source file.
if {$type == "object"} {
set opts "$add_flags $sources"
} else {
set opts "$sources $add_flags"
}
This commit moves the "-x c++" earlier in the compiler's commandline.
Unfortunately this then broke the testcase that required the original
fix, gdb.compile/compile-cplus.exp: the "-x c++" was being parsed for
the linker pass, causing the compiler to attempt to parse the .o files
as C++. This commit makes passing "-x c++" conditional on the source
being a .c file.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_compile): Pass "-x c++" earlier, and only
for .c files.
|
|
Tests that use a secondary MI channel (i.e., either tests that call
mi_gdb_start with separate-mi-tty, or all tests when
FORCE_SEPARATE_MI_TTY=1 is specified on the make check command line),
don't close GDB correctly.
E.g., if you run gdb.mi/mi-exec-run.exp in a loop:
while true; do make check TESTS="gdb.mi/mi-exec-run.exp"; done
you can see more than one gdb running at the same time:
$ ps -ef | grep -v grep | grep "gdb/gdb"
pedro 40507 1 7 15:47 ? 00:00:00 /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory
pedro 40562 1 0 15:47 ? 00:00:00 /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory
pedro 40727 1 0 15:47 ? 00:00:00 /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory
pedro 40786 1 0 15:47 ? 00:00:00 /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory /home/pedro/gdb/build/gdb/testsuite/../data-directory
This commit fixes it.
gdb/testsuite/ChangeLog:
* lib/mi-support.exp (mi_uncatched_gdb_exit) Switch to the main
spawn_id before calling remote_close. Close secondary MI channel.
|
|
With this gdbserver-support.exp patch:
...
@@ -451,8 +451,10 @@ proc gdbserver_exit { is_mi } {
# We use expect rather than gdb_expect because
# we want to suppress printing exception messages, otherwise,
# remote_expect, invoked by gdb_expect, prints the exceptions.
+ set have_prompt 0
expect {
-i "$gdb_spawn_id" -re "$gdb_prompt $" {
+ set have_prompt 1
exp_continue
}
-i "$server_spawn_id" eof {
@@ -463,6 +465,7 @@ proc gdbserver_exit { is_mi } {
warning "Timed out waiting for EOF in server after $monitor_exit"
}
}
+ gdb_assert {$have_prompt}
}
}
close_gdbserver
...
and with this in parallel:
...
$ stress -c 5
...
we run into this and similar FAILs:
...
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
...
In more detail:
...
(gdb) PASS: gdb.multi/multi-target.exp: continue: non-stop=on: inferior 5
Remote debugging from host ::1, port 40712^M
Process build/gdb/testsuite/outputs/gdb.multi/multi-target/multi-target \
created; pid = 11098^M
monitor exit^M
Killing process(es): 11098^M
FAIL: gdb.multi/multi-target.exp: continue: non-stop=on: $have_prompt
spawn build/gdb/testsuite/../../gdb/gdb -nw -nx -data-directory \
build/gdb/testsuite/../data-directory^M
...
After issuing a "monitor exit" command, we should always get a prompt back, so
check for that.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-16 Tom de Vries <tdevries@suse.de>
* lib/gdbserver-support.exp (gdbserver_exit): Make sure we
get the gdb prompt after issuing "monitor exit".
|
|
When running test-case gdb.base/watchpoint-stops-at-right-insn.exp, we may run
into a tcl error, which can be reproduced reliably using this trigger patch:
...
+ set hw_watch_pc ""
gdb_assert {$sw_watch_pc == $hw_watch_pc} \
"hw watchpoint stops at right instruction"
...
such that we have:
...
ERROR: tcl error sourcing watchpoint-stops-at-right-insn.exp.
ERROR: missing operand at _@_
in expression "0x4004b7 == _@_"
(parsing expression "0x4004b7 == ")
invoked from within
"expr $sw_watch_pc == $hw_watch_pc"
("uplevel" body line 1)
invoked from within
"uplevel 1 expr $condition"
(procedure "gdb_assert" line 6)
invoked from within
"gdb_assert {$sw_watch_pc == $hw_watch_pc} \
"hw watchpoint stops at right instruction""
...
A similar problem was fixed in commit 5f0e2eb79e "GDB/testsuite: Fix a
catastrophic step-over-no-symbols.exp failure", by making the assert condition
more robust:
...
- gdb_assert {$before_addr != $after_addr} "advanced"
+ gdb_assert {{[string is integer -strict $before_addr] \
+ && [string is integer -strict $after_addr] \
+ && $before_addr != $after_addr}} "advanced"
...
Fix this instead in gdb_assert, by catching errors while evaluating the assert
condition.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-09-16 Tom de Vries <tdevries@suse.de>
PR testsuite/26624
* lib/gdb.exp (gdb_assert): Catch errors in condition evaluation.
|
|
LLVM 8.0 introduced some changes to let the Rust compiler emit DWARF
variant parts. Before this change, the compiler would emit two types
with the same name, and unfortunately gdb happens to pick the wrong
one. So, this patch disables the test when using an older version of
LLVM.
gdb/testsuite/ChangeLog
2020-09-15 Tom Tromey <tromey@adacore.com>
PR rust/26197:
* lib/rust-support.exp (rust_llvm_version): New proc.
* gdb.rust/simple.exp: Check rust_llvm_version.
|
|
If a board file wants to customize how gdb is launched, the obvious
way is to have the board override gdb_spawn. However, that doesn't
work for either gdb.mi/ testcases or gdb.base/dbx.exp, because
default_mi_gdb_start and dbx_gdb_start don't use gdb_spawn currently.
That is fixed by this patch.
gdb/testsuite/
* gdb.base/dbx.exp (dbx_gdb_start): Adjust to use gdb_spawn
instead of spawning GDB with remote_spawn.
* lib/mi-support.exp (default_mi_gdb_start): Adjust to use
gdb_spawn instead of spawning GDB with remote_spawn.
|
|
Currently -break-insert always creates a wildmatching breakpoint, and
there's no way to ask for a fullname match. To address that, this
patch adds the equivalent of "break -qualified" to MI:
"-break-insert --qualified".
For the testcase, curiously, it doesn't look like we have _any_
testcase that tests a breakpoint with multiple locations, and, the
existing mi_create_breakpoint / mi_make_breakpoint procedures are only
good for breakpoints with a single location. This patch thus adds a
few new companion routines to mi-support.exp for breakpoints with
multiple locations: mi_create_breakpoint_multi,
mi_make_breakpoint_loc, mi_make_breakpoint_multi.
gdb/ChangeLog:
* NEWS: Document "-break-insert --qualified".
* mi/mi-cmd-break.c (mi_cmd_break_insert_1): Handle "--qualified".
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Breakpoint Commands): Document
"-break-insert --qualified" and "-dprintf-insert --qualified".
gdb/testsuite/ChangeLog:
* gdb.mi/mi-break-qualified.cc: New file.
* gdb.mi/mi-break-qualified.exp: New file.
* lib/mi-support.exp (mi_create_breakpoint_multi)
(mi_make_breakpoint_loc, mi_make_breakpoint_multi): New
procedures.
(mi_create_breakpoint_1): New, factored out from
mi_create_breakpoint.
|
|
This adds support for the bfloat16 datatype, which can be seen as a short
version of FP32, skipping the least significant 16 bits of the mantissa.
Since the datatype is currently only supported by the AVX512 registers,
the printing of bfloat16 values is only supported for xmm, ymm and zmm
registers.
gdb/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdbarch.sh: Added bfloat16 type.
* gdbarch.c: Regenerated.
* gdbarch.h: Regenerated.
* gdbtypes.c (floatformats_bfloat16): New struct.
(gdbtypes_post_init): Add builtin_bfloat16.
* gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member.
(floatformats_bfloat16): New struct.
* i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16"
(i386_ymm_type): Add field "v16_bfloat16"
(i386_gdbarch_init): Add set_gdbarch_bfloat16_format.
* target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16.
* gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16.
* gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16.
* features/i386/64bit-avx512.xml: Add bfloat16 type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add bfloat16 type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* x86-avx512bf16.c: New file.
* x86-avx512bf16.exp: Likewise.
* lib/gdb.exp (skip_avx512bf16_tests): New function.
|
|
In the test cases complex.exp,pointer-to-pointer.exp,vla-ptr-info.exp
fortran.exp routines are not used, which are to determine the type/kind
string. Due to this these test incorrectly fail for Flang.
Now test cases are modified to use fortran.exp routines. fortran.exp
file is modified to add absent routines fortran_complex8 and
fortran_complex16.
gdb/testsuite/ChangeLog
* lib/fortran.exp (fortran_complex8): New proc.
(fortran_complex16): New proc.
* gdb.fortran/complex.exp: Use routines from fortran.exp
* gdb.fortran/pointer-to-pointer.exp: Likewise.
* gdb.fortran/vla-ptr-info.exp: Likewise.
|
|
I noticed that when a test uses `runto_main` and a GDB internal error
happens while running to main, no error or fail is emitted. This is
because `runto_main` uses the `no-message` option of `runto`.
As a result, if a test fails to run to main and exits, no sign that
something went wrong is emitted. For example, add this always-false
assertion to compute_frame_id:
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -545,6 +545,7 @@ static void
compute_frame_id (struct frame_info *fi)
{
gdb_assert (!fi->this_id.p);
+ gdb_assert (false);
if (frame_debug)
fprintf_unfiltered (gdb_stdlog, "{ compute_frame_id (fi=%d) ",
... and run gdb.dwarf2/dw2-align.exp. No fail or sign that something
went wrong is shown. It just appears as if the test gets skipped.
A developer introducing such a regression in this test today would
likely notice it, because we are used to diff-ing test results. So we
would see some PASSes dispappear for no good reason and look into it.
But I find it worrysome for two reasons:
1. Scripts that analyze regressions (such as the one on the buildbot)
may only look for new FAILs or new ERRORs. It would probably miss
this.
2. Imagine that we one day have a testsuite that runs cleanly (some
people might already run subsets of the testsuite and expect it to
all pass), we would just run the testsuite and check that there are
no fails. It would be easy to miss something like this.
In case of internal error, I suggest making `runto` emit a FAIL even if
`no-message` was passed. This is different from other failure modes
that might be expected (whchi rightfully cause the test to simply be
skipped). An internal error is always bad, so if it happens it should
noisily fail.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (runto): Always emit fail on internal error.
Change-Id: I6e6faed4868ea821541a23042b2d01c30058b0d3
|
|
In the check-test-names.exp library 'unset' was being used to unset an
array variable. Though this seems to work fine on tcl 8.6, it was
discovered on a CentOS 7.8.2003 machine, running tcl 8.5, that this
doesn't work and 'array unset' should be used instead.
Using 'array unset' should work fine for newer and older versions of
tcl (since 8.3, releases ~2000).
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp (do_reset_vars): Use 'array unset' to
unset the array variable.
|
|
When reading an exec with a .debug_line section containing a vendor-specific
extended opcode, we get:
...
$ gdb -batch -iex "set complaints 10" dw2-vendor-extended-opcode
During symbol reading: mangled .debug_line section
...
and reading of the .debug_line section is abandoned.
The vendor-specific extended opcode should be ignored, as specified in the
DWARF standard (7.1 Vendor Extensibility). [ FWIW, vendor-specific
standard opcodes are already ignored. ]
Fix this by ignoring all vendor-specific extended opcodes.
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* dwarf2/read.c (dwarf_decode_lines_1): Ignore
DW_LNE_lo_user/DW_LNE_hi_user range.
gdb/testsuite/ChangeLog:
2020-08-03 Tom de Vries <tdevries@suse.de>
PR symtab/26333
* lib/dwarf.exp (DW_LNE_user): New proc.
* gdb.dwarf2/dw2-vendor-extended-opcode.c: New test.
* gdb.dwarf2/dw2-vendor-extended-opcode.exp: New file.
|
|
When running test-case gdb.fortran/info-modules.exp with gfortran 4.8.5, I
get:
...
FAIL: gdb.fortran/info-modules.exp: info module functions: \
check for entry 'info-types.f90', '35', \
'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module functions -m mod1: \
check for entry 'info-types.f90', '35', \
'void mod1::__copy_mod1_M1t1\(Type m1t1, Type m1t1\);'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
check for entry 'info-types.f90', '(35)?', \
'Type m1t1 mod1::__def_init_mod1_M1t1;'
FAIL: gdb.fortran/info-modules.exp: info module variables: \
check for entry 'info-types.f90', '(35)?', \
'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;'
...
With gfortran 7.5.0, we have:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
<286> DW_AT_name : __def_init_mod1_M1t1
<29f> DW_AT_name : __vtype_mod1_M1t1
<3de> DW_AT_name : __copy_mod1_M1t1
$
...
but with gfortran 4.8.5:
...
$ readelf -wi info-modules | egrep "DW_AT_name.*(copy|def_init|vtype)_mod1"
$
...
Fix this by allowing these module functions and variables to be missing.
Tested on x86_64-linux with gcc 4.8.5 and gcc 7.5.0.
gdb/testsuite/ChangeLog:
2020-07-30 Tom de Vries <tdevries@suse.de>
* lib/sym-info-cmds.exp (GDBInfoModuleSymbols::check_entry_1): Factor
out of ...
(GDBInfoModuleSymbols::check_entry): ... here.
(GDBInfoModuleSymbols::check_optional_entry): New proc.
* gdb.fortran/info-modules.exp: Use check_optional_entry for entries
related to __def_init_mod1_M1t1 / __vtype_mod1_M1t1 / __copy_mod1_M1t1.
|
|
When building gcc with CFLAGS/CXXFLAGS="-O2 -g", and running the regression
tests, I run into the following FAILs:
...
FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-interrupts.exp: breakpoint in captured_command_loop
FAIL: gdb.gdb/python-selftest.exp: breakpoint in captured_command_loop
...
The problem is that when setting the breakpoint at captured_command_loop:
...
(gdb) break captured_command_loop^M
Breakpoint 1 at 0x4230ed: captured_command_loop. (2 locations)^M
(gdb) FAIL: gdb.gdb/complaints.exp: breakpoint in captured_command_loop
...
there are two breakpoint locations instead of one. This is due to
PR26096 - "gdb sets breakpoint at cold clone":
...
$ nm gdb | grep captured_command_loop| c++filt
0000000000659f20 t captured_command_loop()
00000000004230ed t captured_command_loop() [clone .cold]
...
Work around this by allowing multiple breakpoint locations for
captured_command_loop.
Reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-29 Tom de Vries <tdevries@suse.de>
* lib/selftest-support.exp (selftest_setup): Allow breakpoint at
multiple locations.
|
|
In commit 24ac169ac5a918cd82b7485935f0c40a094c625e, this patch:
2020-02-21 Shahab Vahedi <shahab@synopsys.com>
* lib/gdb.exp (gdb_wrapper_init): Reset
"gdb_wrapper_initialized" to 0 if "wrapper_file" does
not exist.
attempted to fix problems finding the gdb test wrapper gdb_tg.o in
some tests that cd to some non-default directory by rebuilding also
the test wrapper in that directory. This had the side-effect of
leaving these .o files in various places in the GDB source directory
tree.
Furthermore, while the tests that cd to some non-default directory
cannot run on remote host, the code that was added to probe for the
presence of the wrapper file was also specific to host == build.
This patch reverts the problematic parts of that commit and replaces
it with forcing use of an absolute (rather than relative) pathname to
the .o file for linking when host == build.
While debugging this patch, I also observed that use of the construct
"[info exists gdb_wrapper_file]" was not reliable for detecting when
that variable had been initialized by gdb_wrapper_init. I rewrote
that so that the variable is always initialized and has a value of an
empty string when no wrapper file is needed.
2020-07-22 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* lib/gdb.exp (gdb_wrapper_file, gdb_wrapper_flags):
Initialize to empty string at top level.
(gdb_wrapper_init): Revert check for file existence on build.
Build the wrapper in its default place, not a build-specific
location. When host == build, make the pathname absolute.
(gdb_compile): Delete leftover declaration of
gdb_wrapper_initialized. Check gdb_wrapper_file being an empty
string instead of uninitialized.
|
|
In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we
fix a GDB crash:
...
$ valgrind /usr/bin/sleep 10000
==31595== Memcheck, a memory error detector
==31595== Command: /usr/bin/sleep 10000
==31595==
$ gdb /usr/bin/sleep
(gdb) target remote | vgdb --pid=31595
Remote debugging using | vgdb --pid=31595
...
$hex in __GI___nanosleep () at nanosleep.c:27
27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining);
(gdb) p printf ("bla")
terminate called after throwing an instance of 'gdb_exception_error'
Aborted (core dumped)
...
This patch adds a test-case for it.
Unfortunately, I was not able to trigger the error condition using a regular
vgdb_start, so I've added a parameter active_at_startup, and when set to 0
this causes valgrind to be started without --vgdb-error=0.
Tested on x86_64-linux.
Tested with the commit mentioned above reverted, resulting in:
...
(gdb) p printf ("bla")^M
terminate called after throwing an instance of 'gdb_exception_error'^M
ERROR: GDB process no longer exists
GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT
UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf
...
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* gdb.base/valgrind-infcall-2.c: New test.
* gdb.base/valgrind-infcall-2.exp: New file.
* lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.
|
|
The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src
parameter, which is set to $srcdir/$subdir/$srcfile in every single call.
Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the
procs.
Build and reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop
src parameter.
* gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls.
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-opt-structptr.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/implptr-optimized-out.exp: Same.
* gdb.dwarf2/implref-array.exp: Same.
* gdb.dwarf2/implref-const.exp: Same.
* gdb.dwarf2/implref-global.exp: Same.
* gdb.dwarf2/implref-struct.exp: Same.
* gdb.dwarf2/info-locals-optimized-out.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
* gdb.dwarf2/var-access.exp: Same.
* gdb.dwarf2/varval.exp: Same.
* gdb.trace/entry-values.exp: Same.
|
|
The file lib/dwarf.exp contains:
...
# Declare a global label. This is typically used to refer to
# labels defined in other files, for example a function defined in
# a .c file.
proc extern {args} {
foreach name $args {
_op .global $name
}
}
...
The assembler directive to refer to labels defined in other files is
not .global, but .extern, and that one is ignored by gas.
Since we require gas for all dwarf assembly test-cases, remove the proc and
all it's uses.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-17 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (Dwarf::extern): Remove.
* gdb.compile/compile-ops.exp: Remove use of Dwarf::extern.
* gdb.dlang/circular.exp: Same.
* gdb.dwarf2/comp-unit-lang.exp: Same.
* gdb.dwarf2/dw2-ifort-parameter.exp: Same.
* gdb.dwarf2/dw2-symtab-includes.exp: Same.
* gdb.dwarf2/dwz.exp: Same.
* gdb.dwarf2/imported-unit-abstract-const-value.exp: Same.
* gdb.dwarf2/imported-unit-runto-main.exp: Same.
* gdb.dwarf2/imported-unit.exp: Same.
* gdb.dwarf2/opaque-type-lookup.exp: Same.
|
|
There's an idiom in dwarf assembly test-cases:
...
set line1 [gdb_get_line_number "line 1"]
set line2 [gdb_get_line_number "line 2"]
set line3 [gdb_get_line_number "line 3"]
...
{DW_LNS_advance_line [expr $line1 - 1]}
...
{DW_LNS_advance_line [expr $line2 - $line1]}
...
{DW_LNS_advance_line [expr $line3 - $line2]}
...
Add a pseudo line number program instruction "line", such that we can simply
write:
...
{line $line1}
...
{line $line2}
...
{line $line3}
...
Build and reg-tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-16 Tom de Vries <tdevries@suse.de>
* lib/dwarf.exp (program): Initialize _line.
(DW_LNE_end_sequence): Reinitialize _line.
(DW_LNS_advance_line): Update _line.
(line): New proc.
* gdb.dwarf2/dw2-inline-many-frames.exp: Use line.
* gdb.dwarf2/dw2-inline-small-func.exp: Same.
* gdb.dwarf2/dw2-inline-stepping.exp: Same.
* gdb.dwarf2/dw2-is-stmt-2.exp: Same.
* gdb.dwarf2/dw2-is-stmt.exp: Same.
* gdb.dwarf2/dw2-ranges-func.exp: Same.
|
|
The comments modified in this patch claim that the addr_size parameters
can take the value 32 or 64 (suggesting the value is in bits). In fact,
the expected value is in bytes, either 4 or 8.
The actual value in the DWARF info is in bytes. And we can see that the
default values used (if addr_size == "default") are:
if {$_cu_addr_size == "default"} {
if {[is_64_target]} {
set _cu_addr_size 8
} else {
set _cu_addr_size 4
}
}
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (Dwarf::cu, Dwarf::tu, Dwarf::lines): Change valid
values in documentation for addr_size to 4 and 8.
Change-Id: I4a02dca2bb7992198864e545ef099f020f54ff2f
|
|
When running test-case gdb.base/morestack.exp without the gold linker
installed, we run into:
...
Running src/gdb/testsuite/gdb.base/morestack.exp ...
gdb compile failed, collect2: fatal error: cannot find 'ld'
compilation terminated.
FAIL: gdb.base/morestack.exp: continue
=== gdb Summary ===
nr of expected passes 1
nr of unexpected failures 1
nr of untested testcases 1
...
The test-case needs the gold linker to run correctly (as explained in commit
b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but
only prefers it, and doesn't require it.
Fix this by requiring the gold linker in the test-case. Furthermore, silence
the compilation error by introducing a caching proc have_fuse_ld_gold and
using it in this and other test-cases that use -fuse-ld=gold.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-07-13 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (have_fuse_ld_gold): New caching proc.
* gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold.
* gdb.base/gold-gdb-index.exp: Same.
* gdb.base/morestack.exp: Same.
|
