The DW_AT_data_bit_offset attribute was introduced by DWARF V4 and
allows specifying the offset of a data member within its containing
entity. But although the new attribute was intended to replace
DW_AT_bit_offset for this purpose, GDB ignores it, and thus GCC still
emits DW_AT_bit_offset instead. See also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71669.
This change fixes GDB's lack of support for DW_AT_data_bit_offset and
adds an appropriate test case.
gdb/ChangeLog:
PR gdb/12616
* dwarf2read.c (dwarf2_add_field): Handle the DWARF V4 attribute
DW_AT_data_bit_offset.
gdb/testsuite/ChangeLog:
PR gdb/12616
* gdb.dwarf2/nonvar-access.exp: New testcase. Check that GDB
respects the DW_AT_data_bit_offset attribute.
I find the big file lists in the Makefiles a bit ugly and not very
practical. Since there are multiple filenames on each line (as much as
fits in 80 columns), it's not easy to add, remove or change a name in
the middle. As a result, we have a mix of long and short lines in no
particular order (ALL_TARGET_OBS is a good example).
I therefore suggest flattening the lists (one name per line) and keeping
them in alphabetical order. The diffs will be much clearer and merge
conflicts will be easier to resolve.
A nice (IMO) side-effect I observed is that the files are compiled
alphabetically by make, so it gives a rough idea of the progress of the
build.
I added a comment in gdb/Makefile.in to mention to keep the file lists
ordered, and gave the general guidelines on what order to respect. I
added a comment in other Makefiles which refers to gdb/Makefile.in, to
avoid duplication.
Running the patch through the buildbot found that gdb.base/default.exp
started to fail. The languages in the error message shown when typing
"set language" have changed order. We could probably improve gdb so
that it prints them in a stable order, regardless of the order of the
object list passed to the linked, but just fixing the test is easier for
now.
New in v2:
- Change ordering style, directories go at the end.
- Cleanup gdbserver's and data-directory's Makefile as well.
- Add comments at top of Makefiles about the ordering.
- Remove wrong trailing backslahes.
- Fix test gdb.base/default.exp.
gdb/ChangeLog:
* Makefile.in: Add comment about file lists ordering.
(SUBDIR_CLI_OBS, SUBDIR_CLI_SRCS, SUBDIR_MI_OBS, SUBDIR_MI_SRCS,
SUBDIR_TUI_OBS, SUBDIR_TUI_SRCS, SUBDIR_GCC_COMPILE_OBS,
SUBDIR_GCC_COMPILE_SRCS, SUBDIR_GUILE_OBS, SUBDIR_GUILE_SRCS,
SUBDIR_PYTHON_OBS, SUBDIR_PYTHON_SRCS, SUBDIR_GDBTK_OBS,
SUBDIR_GDBTK_SRCS, XMLFILES, REMOTE_OBS, ALL_64_TARGET_OBS,
ALL_TARGET_OBS, SFILES, HFILES_NO_SRCDIR, HFILES_WITH_SRCDIR,
COMMON_OBS, YYFILES, YYOBJ, generated_files, ALLDEPFILES):
Flatten list and order alphabetically.
* data-directory/Makefile.in: Add comment about file lists
ordering.
(GEN_SYSCALLS_FILES, PYTHON_FILE_LIST): Flatten list and order
alphabetically.
gdb/gdbserver/ChangeLog:
* Makefile.in (SFILES, OBS): Flatten list and order
alphabetically.
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Fix output of "set language".
Since GNU make is now required to build GDB, we can remove everything
that checks whether the current make implemention is the GNU one or
not. I simply removed the @GMAKE_TRUE@ prefixes and removed the whole
lines that were prefixed with @GMAKE_FALSE@.
I removed the code in the configure scripts that set those variables.
I also removed the following bits from the configure scripts:
AC_CHECK_PROGS(MAKE, make): GNU make already defines a MAKE variable
internally to be used when invoking Makefiles recursively. I don't see
this variable being used anywhere else (in scripts for example), so I
think it's safe for removal.
AC_PROG_MAKE_SET: This macro defines a SET_MAKE output variable, which
is meant to be used in Makefiles to define the MAKE variable when
using an implementation of make that doesn't already define it.
Since we are now requiring GNU make, we don't need it anymore.
Plus, I don't see SET_MAKE being used anywhere, so I don't think it
was actually doing anything...
gdb/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
gdb/gdbserver/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
gdb/testsuite/ChangeLog:
* Makefile.in: Remove @GMAKE_TRUE@ prefixes and removes lines
prefixed with @GMAKE_FALSE@. Update comment related to non-GNU
make.
* configure.ac: Remove checks for the make program.
* configure: Re-generate.
This patch modifies the unwinder (sniffer) defined in
py-recurse-unwind.py so that, depending upon the value of one of its
class variables, it will take different paths through the code,
testing different functionality.
The original test attempted to obtain the value of an undefined
symbol.
This somewhat expanded test checks to see if 'pc' can be read via
gdb.PendingFrame.read_register() and also via gdb.parse_and_eval().
gdb/testsuite/ChangeLog:
* gdb.python/py-recurse-unwind.c (main): Add loop.
* gdb.python/py-recurse-unwind.py (TestUnwinder): Add calls
to read_register() and gdb.parse_and_eval(). Make each code
call a separate case that can be individually tested.
* gdb.python/py-recurse-unwind.exp (cont_and_backtrace): New
proc. Call cont_and_backtrace for each of the code paths that
we want to test in the unwinder.
The "struct S" type in bitfield-parent-optimized-out.exp is declared to
have a size of 4 bytes but to hold two 4-byte members: an int-based
bitfield and a 4-byte int. Also, both members have the same
data_member_location 2, causing them to overlap and to reach 2 bytes
beyond the structure's boundary.
This is fixed by increasing the structure size to 8 and setting the
first and second member's data_member_location to 0 and 4, respectively.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/bitfield-parent-optimized-out.exp: Fix DWARF code for
the definition of struct S.
- Use multi_line for matching multi-line GDB output.
- Add a multi_line_input variant of multi_line to build GDB input and
use it throughout.
(The two changes above make the tests much more readable, IMO.)
- Add a new valnum_re global to get rid of the multiple "\\\$\[0-9\]*".
- Remove gdb_stop_suppressing_tests uses.
- tighten a few regexps.
- Replace send_gdb/gdb_expect with gdb_test_multiple and simplify,
making pass/fail messages the same.
gdb/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (runto_or_return): New procedure.
(gdbvar_simple_if_test, gdbvar_simple_while_test)
(gdbvar_complex_if_while_test, progvar_simple_if_test)
(progvar_simple_while_test, progvar_complex_if_while_test)
(if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, redefine_hook_test)
(stray_arg0_test, error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use runto_or_return, $valnum_re,
multi_line_input and multi_line. Remove gdb_expect and
gdb_stop_suppressing_tests uses.
* lib/gdb.exp (valnum_re): New global.
* lib/gdb.exp (valnum_re): New global.
(multi_line_input): New procedure.
Pedro's patch provides a cleaner way to prefix tests with the proc name,
so let's use that.
gdb/testsuite/ChangeLog:
* gdb.mi/user-selected-context-sync.exp (with_test_prefix_procname):
Remove.
(test_setup): Define with proc_with_prefix.
(test_cli_inferior): Likewise.
(test_cli_thread): Likewise.
(test_cli_frame): Likewise.
(test_cli_select_frame): Likewise.
(test_cli_up_down): Likewise.
(test_mi_thread_select): Likewise.
(test_mi_stack_select_frame): Likewise.
(test_cli_in_mi_inferior): Likewise.
(test_cli_in_mi_thread): Likewise.
(test_cli_in_mi_frame): Likewise.
(top level): Do not use with_test_prefix_procname.
While adding new tests to gdb.base/commands.exp, I noticed that the
file includes a bunch of individual testcases split into their own
procedures, and that none have ever been adjusted to use
with_test_prefix. Instead, each gdb_test/gdb_test_multiple/etc
invocation takes care of including the procedure name in the test
message, in order to make sure test messages are unique.
Simon convinced me that using the procedure name as prefix is not that
bad of an idea:
https://sourceware.org/ml/gdb-patches/2016-10/msg00020.html
This commit adds an IMO simpler alternative to
with_test_prefix_procname added by that patch -- a new
"proc_with_prefix" convenience proc that is meant to be used in place
of "proc", and then uses it in commands.exp. Procedures defined with
this automatically run their bodies under with_test_prefix $proc_name.
Here's a sample of the resulting gdb.sum diff:
[...]
-PASS: gdb.base/commands.exp: break factorial #3
-PASS: gdb.base/commands.exp: set value to 5 in test_command_prompt_position
-PASS: gdb.base/commands.exp: if test in test_command_prompt_position
-PASS: gdb.base/commands.exp: > OK in test_command_prompt_position
+PASS: gdb.base/commands.exp: test_command_prompt_position: break factorial
+PASS: gdb.base/commands.exp: test_command_prompt_position: set value to 5
+PASS: gdb.base/commands.exp: test_command_prompt_position: if test
+PASS: gdb.base/commands.exp: test_command_prompt_position: > OK
[...]
gdb/testsuite/ChangeLog:
2016-11-09 Pedro Alves <palves@redhat.com>
* gdb.base/commands.exp (gdbvar_simple_if_test)
(gdbvar_simple_while_test, gdbvar_complex_if_while_test)
(progvar_simple_if_test, progvar_simple_while_test)
(progvar_complex_if_while_test, if_while_breakpoint_command_test)
(infrun_breakpoint_command_test, breakpoint_command_test)
(user_defined_command_test, watchpoint_command_test)
(test_command_prompt_position, deprecated_command_test)
(bp_deleted_in_command, temporary_breakpoint_commands)
(stray_arg0_test, source_file_with_indented_comment)
(recursive_source_test, if_commands_test)
(error_clears_commands_left, redefine_hook_test)
(redefine_backtrace_test): Use proc_with_prefix.
* lib/gdb.exp (proc_with_prefix): New proc.
A user reported a GDB crash with TUI when trying to debug a function
with a long demangled C++ method name. It turned out that the logic for
displaying the TUI disassembly window has a bug that can cause a buffer
overrun, possibly overwriting GDB-internal data structures. In
particular, the logic performs an unguarded strcpy.
Another (harmless) bug in tui_alloc_source_buffer causes the buffer to
be two lines longer than needed. This may have made the crash appear
less frequently.
gdb/ChangeLog:
* tui/tui-disasm.c (tui_set_disassem_content): Fix line buffer
overrun due to unchecked strcpy.
gdb/testsuite/ChangeLog:
* gdb.base/tui-layout.c: New file.
* gdb.base/tui-layout.exp: Use tui-layout.c, to ensure that the
disassembly window contains very long lines.
I happened to notice that one test in py-value.exp did not work
properly with Python 3. This patch fixes the problem.
2016-11-08 Tom Tromey <tom@tromey.com>
* gdb.python/py-value.exp (test_value_creation): Make "long" test
depend on Python 2.
While writing a Python frame filter, I found a few bugs in the current
frame filter code. In particular:
* One spot converts a Python long to a CORE_ADDR using PyLong_AsLong.
However, this can fail on overflow. I changed this to use
get_addr_from_python.
* Another spot is doing the same but with PyLong_AsUnsignedLongLong; I
changed this as well just for consistency.
* Converting line numbers can print "-1" if conversion from long
fails. This isn't fatal but just a bit ugly.
I've included a test case for the first issue. The line number one
didn't seem important enough to bother with.
2016-11-08 Tom Tromey <tom@tromey.com>
* python/py-framefilter.c (py_print_frame): Use
get_addr_from_python. Check for errors when getting line number.
2016-11-08 Tom Tromey <tom@tromey.com>
* gdb.python/py-framefilter.py (ElidingFrameDecorator.address):
New method.
2016-10-27 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_get_disr_info): Treat univariant enums
without discriminants as encoded enums with a real field
* rust-lang.c (rust_evaluate_subexp): Handle field access
on encoded struct-like enums
gdb/testsuite/ChangeLog:
* simple.rs: Add test for univariant enums without discriminants
and for encoded struct-like enums
* simple.exp: Add test expectations
Fixes:
PASS: gdb.base/maint.exp: maint w/o args
ERROR: internal buffer is full.
UNRESOLVED: gdb.base/maint.exp: maint info line-table w/o a file name
The problem is just many symtabs and long line tables, enough to
overflow the expect buffer. Fix this by matching input incrementally.
gdb/testsuite/ChangeLog:
2016-10-28 Pedro Alves <palves@redhat.com>
* gdb.base/maint.exp <maint info line-table w/o a file name>: Use
gdb_test_multiple, tighten regexps and match symtabs and line
tables incrementally.
Testing a powerpc toolchain running gdbserver on the other end i noticed a
failure in gdb.base/foll-exec.exp. Turns out gdb is outputting a slightly
different pattern due to the presence of debug information.
--
foll-exec is about to execlp(execd-prog)...^M
Continuing.^M
process 21222 is executing new program: gdb.d/outputs/gdb.base/foll-exec/execd-prog^M
^M
Catchpoint 2 (exec'd gdb.d/outputs/gdb.base/foll-exec/execd-prog), _start () at ../sysdeps/powerpc/powerpc32/dl-start.S:32^M
--
Notice the presence of source file information.
Now, on my local machine, i get this:
--
foll-exec is about to execlp(execd-prog)...^M
Continuing.^M
process 9285 is executing new program: gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog^M
^M
Catchpoint 2 (exec'd gdb/testsuite/outputs/gdb.base/foll-exec/execd-prog), 0x00007ffff7dd7cc0 in ?? () from /lib64/ld-linux-x86-64.so.2^M
--
So the output differs slightly and the testcase is actually expecting only
the second form with the "in" anchor.
This patch removes the "in" pattern and lets the test match both kinds of
output.
gdb/testsuite/ChangeLog:
2016-10-28 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/foll-exec.exp (do_exec_tests): Make test pattern more
general.
The following testcases make GDB crash whenever an invalid sysroot is
provided, when GDB is unable to find a valid path to the symbol file:
gdb.base/catch-syscall.exp
gdb.base/execl-update-breakpoints.exp
gdb.base/foll-exec-mode.exp
gdb.base/foll-exec.exp
gdb.base/foll-vfork.exp
gdb.base/pie-execl.exp
gdb.multi/bkpt-multi-exec.exp
gdb.python/py-finish-breakpoint.exp
gdb.threads/execl.exp
gdb.threads/non-ldr-exc-1.exp
gdb.threads/non-ldr-exc-2.exp
gdb.threads/non-ldr-exc-3.exp
gdb.threads/non-ldr-exc-4.exp
gdb.threads/thread-execl.exp
The immediate cause of the segv is that follow_exec is passing a NULL
argument (the result of exec_file_find) to strlen.
However, the problem is deeper than that: follow_exec simply isn't
prepared for the case where sysroot translation fails to locate the
new executable. Actually all callers of exec_file_find have bugs due
to confusion between host and target pathnames. This commit attempts
to fix all that.
In terms of the testcases that were formerly segv'ing, GDB now prints
a warning but continues execution of the new program, so that the
tests now mostly FAIL instead. You could argue the FAILs are due to a
legitimate problem with the test environment setting up the sysroot
translation incorrectly.
A new representative test is added which exercises the ne wwarning
code path even with native testing.
Tested on x86_64 Fedora 23, native and gdbserver.
gdb/ChangeLog:
2016-10-25 Sandra Loosemore <sandra@codesourcery.com>
Luis Machado <lgustavo@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR gdb/20569
* exceptions.c (exception_print_same): Moved here from exec.c.
* exceptions.h (exception_print_same): Declare.
* exec.h: Include "symfile-add-flags.h".
(try_open_exec_file): New declaration.
* exec.c (exception_print_same): Moved to exceptions.c.
(try_open_exec_file): New function.
(exec_file_locate_attach): Rename exec_file and full_exec_path
variables to avoid confusion between target and host pathnames.
Move pathname processing logic to exec_file_find. Do not return
early if pathname lookup fails; Call try_open_exec_file.
* infrun.c (follow_exec): Split and rename execd_pathname variable
to avoid confusion between target and host pathnames. Warn if
pathname lookup fails. Pass target pathname to
target_follow_exec, not hostpathname. Call try_open_exec_file.
* main.c (symbol_file_add_main_adapter): New function.
(captured_main_1): Use it.
* solib-svr4.c (open_symbol_file_object): Adjust to pass
symfile_add_flags to symbol_file_add_main.
* solib.c (exec_file_find): Incorporate fallback logic for relative
pathnames formerly in exec_file_locate_attach.
* symfile.c (symbol_file_add_main, symbol_file_add_main_1):
Replace 'from_tty' parameter with a symfile_add_file.
(symbol_file_command): Adjust to pass symfile_add_flags to
symbol_file_add_main.
* symfile.h (symbol_file_add_main): Replace 'from_tty' parameter
with a symfile_add_file.
gdb/testsuite/ChangeLog:
2016-10-25 Luis Machado <lgustavo@codesourcery.com>
* gdb.base/exec-invalid-sysroot.exp: New file.
Since
[commit] [testsuite patch] Fix gcc_compiled for gcc 6 & 7
https://sourceware.org/ml/gdb-patches/2016-10/msg00620.html
there has started running again
Running gdb/testsuite/gdb.base/morestack.exp ...
+FAIL: gdb.base/morestack.exp: continue
+PASS: gdb.base/morestack.exp: up 3000
but as you can see it FAILs now - on Fedora 24 x86_64 (although for example it
still PASSes on CentOS-7.2 x86_64).
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff787c7bb in malloc_consolidate (av=av@entry=0x7ffff7bbcb00 <main_arena>) at malloc.c:4181
4181 unlink(av, nextchunk, bck, fwd);
(gdb) bt
[...]
[...]
This apparently is due to - man gcc - -fsplit-stack:
When code compiled with -fsplit-stack calls code compiled without
-fsplit-stack, there may not be much stack space available for the
latter code to run. If compiling all code, including library code,
with -fsplit-stack is not an option, then the linker can fix up these
calls so that the code compiled without -fsplit-stack always has
a large stack. Support for this is implemented in the gold linker in
GNU binutils release 2.21 and later.
gdb/testsuite/ChangeLog
2016-10-24 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/morestack.exp: Try to build it using -fuse-ld=gold first.
Fix a commit 4a556533cf ("Fix PR11094: JIT breakpoint is not properly
recreated on reruns") regression:
Running .../gdb/testsuite/gdb.base/killed-outside.exp ...
Executing on host: mips-mti-linux-gnu-gcc -Wl,--no-as-needed -c -g -o .../gdb/testsuite/outputs/gdb.base/killed-outside/killed-outside0.o .../gdb/testsuite/gdb.base/killed-outside.c .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so (timeout = 300)
spawn mips-mti-linux-gnu-gcc -Wl,--no-as-needed -c -g -o .../gdb/testsuite/outputs/gdb.base/killed-outside/killed-outside0.o .../gdb/testsuite/gdb.base/killed-outside.c .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so
mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
output is:
mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
gdb compile failed, mips-mti-linux-gnu-gcc: warning: .../gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple-jit.so: linker input file unused because linking not done
UNTESTED: gdb.base/killed-outside.exp: failed to prepare
and adjust the call to `prepare_for_testing' by removing a reference to
`options', which is not set in this test case but a stale value is
carried over from `gdb.base/jit-simple.exp' previously executed in a
full test suite run.
gdb/testsuite/
* gdb.base/killed-outside.exp: Remove $options from a call to
`prepare_for_testing'.
This fixes a comment I forgot to update in the previous patch.
gdb/testsuite/ChangeLog:
* gdb.trace/mi-trace-save.exp (test_trace_save_wrong_num_args):
Update comment.
-trace-save doesn't check whether an argument is passed, leading to a
segfault if you pass nothing.
I added a small test, which only tests the error conditions of
-trace-save.
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_trace_save): Check if argument is present
before using it.
gdb/testsuite/ChangeLog:
* gdb.trace/mi-trace-save.exp: New file.
This patch skips some tests related to floating point in structs.exp
if gdb_skip_float_test return false.
gdb/testsuite:
2016-10-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/structs.exp: Invoke gdb_skip_float_test, and do
floating point tests if $skip_float_test is false.
I noticed that testing aarch64-elf gdb with a physical board
ran into issues with gdb.python/py-value.exp. Further investigation showed
that we were actually trying to dereference a NULL pointer (argv) when trying
to access argv[0].
Being bare-metal, argv is not guaranteed to be valid. So we need to make sure
argv is sane before accessing argv[0].
The following patch fixes up the test program to check for a NULL argv and also
improves the testcase a bit so it doesn't have to work with a hardcoded argc
value.
Regression-tested on x86-64 Ubuntu 16.04.
gdb/testsuite/ChangeLog:
2016-10-12 Luis Machado <lgustavo@codesourcery.com>
* gdb.python/py-value.c (main): Check if argv is NULL before using it.
* gdb.python/py-value.exp (test_value_in_inferior): Don't use hardcoded
argc values.
Add 1 to argc so we guarantee distinct initial/modified argc values.
gcc-6.2.1
gdb compile failed, gdb/testsuite/gdb.arch/powerpc-prologue.c: In function 'main':
gdb/testsuite/gdb.arch/powerpc-prologue.c:32:3: warning: implicit declaration of function 'optimized_1' [-Wimplicit-function-declaration]
optimized_1 ();
^~~~~~~~~~~
gdb/testsuite/ChangeLog
2016-10-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/powerpc-prologue.c (optimized_1): New declaration.
0a69eedb (Clean up the XML files for ARM) moves arm-*.xml files to
arm/ directory, so need update gdb.xml/tdesc-regs.exp accordingly.
gdb/testsuite:
2016-10-07 Yao Qi <yao.qi@linaro.org>
* gdb.xml/tdesc-regs.exp: Set regdir to "arm/".
The gdb.decode_line python function is documented to support the same location
expressions as the "break" command. It currently expects a linespec location.
Instead of creating a linespec location directly, create the location via
string_to_event_location_basic.
Fix a regression from commit f8b73d13b7 ("Target-described register
support for MIPS"),
<https://sourceware.org/ml/gdb-patches/2007-05/msg00340.html>,
<https://sourceware.org/ml/gdb-patches/2007-06/msg00256.html>, which
caused Floating Point Control Registers (FCRs) to be shown as 64-bit
with 64-bit targets.
This came from the legacy register format where all raw registers
matched the width of the architecture regardless of their actual size.
The correct size was then set in `mips_register_type' for cooked
registers presented to the user, which in the case of FCRs meant the
cooked size was always forced to 32 bits, reflecting their actual
hardware size, even though the raw format carried them in 64-bit
quantities on 64-bit targets. The upper 32 bits carried in the raw FCR
format have always been don't-cares, not actually retrieved from
hardware and never written back.
With the introduction of XML register descriptions the layout of
previously defined raw registers has been preserved, so as to keep
existing register handling code unchanged and make it easier for GDB and
`gdbserver' to interact with each other whether neither, either or both
parties talking over RSP support XML register descriptions. For the
XML-described case however `mips_register_type' is not used in raw to
cooked register conversion, so any special cases coded there are not
taken into account.
Instead a new function, `mips_pseudo_register_type', has been introduced
to handle size conversion, however lacking the special case for FCRs for
the Linux and the now defunct IRIX target. The correct size has been
maintained for embedded targets however, due to the bundling of FCRs
with the embedded registers under the `rawnum >= MIPS_EMBED_FP0_REGNUM +
32' condition.
Add the missing case to `mips_pseudo_register_type' then, referring to
the FCR indices explicitly, and observing that between
`MIPS_EMBED_FP0_REGNUM + 32' and `MIPS_FIRST_EMBED_REGNUM' there is an
unused register slot whose contents are ignored so with the removal of
embedded FCRs from under that condition we don't have to care about it
and we can refer to the embedded registers starting from
MIPS_FIRST_EMBED_REGNUM instead.
Add a test case too so that we have means to check automatically that
the correct user-visible size of FCRs is maintained.
gdb/
* mips-tdep.c (mips_pseudo_register_type): Make FCRs always
32-bit.
gdb/testsuite/
* gdb.arch/mips-fcr.exp: New test.
* gdb.arch/mips-fcr.c: Source for the new test.
Correct a commit 2151ccc56c ("Always organize test artifacts in a
directory hierarchy") regression causing:
Running .../gdb/testsuite/gdb.base/solib-disc.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.base/so-disc-shr.c.o: No such file or directory
by using `standard_output_file' to construct output file names
throughout.
gdb/testsuite/
* gdb.base/solib-disc.exp: Use `standard_output_file'
throughout.
Even though this was supposedly in the gdb 7.2 timeframe, the testcase
in PR11094 crashes current GDB with a segfault:
Program received signal SIGSEGV, Segmentation fault.
0x00000000005ee894 in event_location_to_string (location=0x0) at
src/gdb/location.c:412
412 if (EL_STRING (location) == NULL)
(top-gdb) bt
#0 0x00000000005ee894 in event_location_to_string (location=0x0) at
src/gdb/location.c:412
#1 0x000000000057411a in print_breakpoint_location (b=0x18288e0, loc=0x0) at
src/gdb/breakpoint.c:6201
#2 0x000000000057483f in print_one_breakpoint_location (b=0x18288e0,
loc=0x182cf10, loc_number=0, last_loc=0x7fffffffd258, allflag=1)
at src/gdb/breakpoint.c:6473
#3 0x00000000005751e1 in print_one_breakpoint (b=0x18288e0,
last_loc=0x7fffffffd258, allflag=1) at
src/gdb/breakpoint.c:6707
#4 0x000000000057589c in breakpoint_1 (args=0x0, allflag=1, filter=0x0) at
src/gdb/breakpoint.c:6947
#5 0x0000000000575aa8 in maintenance_info_breakpoints (args=0x0, from_tty=0)
at src/gdb/breakpoint.c:7026
[...]
This is GDB trying to print the location spec of the JIT event
breakpoint, but that's an internal breakpoint without one.
If I add a NULL check, then we see that the JIT breakpoint is now
pending (because its location has shlib_disabled set):
(gdb) maint info breakpoints
Num Type Disp Enb Address What
[...]
-8 jit events keep y <PENDING> inf 1
[...]
But that's incorrect. GDB should have managed to recreate the JIT
breakpoint's location for the second run. So the problem is
elsewhere.
The problem is that if the JIT loads at the same address on the second
run, we never recreate the JIT breakpoint, because we hit this early
return:
static int
jit_breakpoint_re_set_internal (struct gdbarch *gdbarch,
struct jit_program_space_data *ps_data)
{
[...]
if (ps_data->cached_code_address == addr)
return 0;
[...]
delete_breakpoint (ps_data->jit_breakpoint);
[...]
ps_data->jit_breakpoint = create_jit_event_breakpoint (gdbarch, addr);
Fix this by deleting the breakpoint and discarding the cached code
address when the objfile where the previous JIT breakpoint was found
is deleted/unloaded in the first place.
The test that was originally added for PR11094 doesn't trip on this
because:
#1 - It doesn't test the case of the JIT descriptor's address _not_
changing between reruns.
#2 - And then it doesn't do "maint info breakpoints", or really
anything with the JIT at all.
#3 - and even then, to trigger the problem the JIT descriptor needs
to be in a separate library, while the current test puts it in
the main program.
The patch extends the test to cover all combinations of these
scenarios.
gdb/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* jit.c (free_objfile_data): Delete the JIT breakpoint and clear
the cached code address.
gdb/testsuite/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* gdb.base/jit-simple-dl.c: New file.
* gdb.base/jit-simple-jit.c: New file, factored out from ...
* gdb.base/jit-simple.c: ... this.
* gdb.base/jit-simple.exp (jit_run): Delete.
(build_jit): New proc.
(jit_test_reread): Recompile either the main program or the shared
library, depending on what is being tested. Skip changing address
if caller wants to. Compare before/after addresses. If testing
standalone, explicitly load the binary. Test "maint info
breakpoints".
(top level): Add "standalone vs shared lib" and "change address"
vs "same address" axes.
I noticed that we sometimes get this:
(gdb) print &__jit_debug_descriptor
$1 = (struct jit_descriptor *) 0x601040 <__jit_debug_descriptor>
(gdb) PASS: gdb.base/jit-simple.exp: blah 1
[...]
(gdb) run
[...]
Starting program: build/gdb/testsuite/outputs/gdb.base/jit-simple/jit-simple
Unsupported JIT protocol version 4 in descriptor (expected 1)
Breakpoint 2, main () at src/gdb/testsuite/gdb.base/jit-simple.c:36
36 return 0;
(gdb) print &__jit_debug_descriptor
$2 = (struct jit_descriptor *) 0x601040 <__jit_debug_descriptor>
(gdb) PASS: gdb.base/jit-simple.exp: blah 1
All tests PASSed, but note the "Unsupported JIT protocol version 4"
message.
Also notice that "__jit_debug_descriptor" has the same address before
and after the rerun, while the test is built in a way that should make
that address change between runs.
The test doesn't catch any of this because it doesn't compare
before/after addresses.
And then notice the "blah 1" test messages. "blah" is clearly a WIP
message, but it should be at least "blah 2" the second time. :-)
The reason this sometimes happens is that the test recompiles the
program and expects gdb to reload it automaticallyt on "run". However,
if the original program and the new recompilation happen to be in the
same second, then gdb does not realize that the binary needs to be
reloaded. (This is an old problem out of scope of this series.) If
that happens, then GDB ends up using the wrong symbols for the program
that it spawns, reads the JIT descriptor out of the wrong address,
finds garbage, and prints that "unsupported version" notice.
Fix that in the same way gdb.base/reread.exp handles it -- by sleeping
one second before recompiling.
gdb/testsuite/ChangeLog:
2016-10-06 Pedro Alves <palves@redhat.com>
* gdb.base/jit-simple.exp (top level) Delete get_compiler_info
call.
(jit_run): Delete.
(jit_test_reread): Use with_test_prefix. Reload the main binary
explicitly. Compare the before/after addresses of the JIT
descriptor.
Newer gdbservers may be talking to older gdbs,
and older gdbs will flag a missing "end" as an error.
So just make "end" required again, and for compatibility
change the default field type to "bool".
gdb/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* features/aarch64-core.xml (cpsr_flags): Elide "type" and specify
"end" in all fields.
* features/aarch64.c: Regenerate.
* features/i386/32bit-mpx.xml (_bndcfgu): Specify type of "preserved"
and "enabled" fields. Correct size of "enabled" field.
* features/i386/64bit-mpx.xml (_bndcfgu): Specify type of "preserved"
and "enabled" fields.
* features/i386/i386-avx-mpx-linux.c: Regenerate.
* features/i386/i386-avx-mpx.c: Regenerate.
* features/i386/i386-avx512-linux.c: Regenerate.
* features/i386/i386-avx512.c: Regenerate.
* features/i386/i386-mpx-linux.c: Regenerate.
* features/i386/i386-mpx.c: Regenerate.
* features/arc-arcompact.c: Regenerate.
* features/arc-v2.c: Regenerate.
* xml-tdesc.c (tdesc_start_field): Require "end" spec. Single bit
fields default to "bool" type.
Revert 2016-03-15 Doug Evans <dje@google.com>
* features/i386/32bit-core.xml (i386_eflags): Remove "end" spec.
* features/i386/32bit-sse.xml (i386_eflags): Ditto.
* features/i386/64bit-core.xml (i386_eflags): Ditto.
* features/i386/64bit-sse.xml (i386_eflags): Ditto.
* features/i386/x32-core.xml (i386_eflags): Ditto.
gdb/doc/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* gdb.texinfo (Target Description Format): Update docs on "end"
field spec and field default type.
gdb/testsuite/ChangeLog:
2016-10-06 Doug Evans <dje@google.com>
* gdb.xml/extra-regs.xml: Update, end field now required, default type
for single bitfields is bool.
* gdb.xml/tdesc-regs.exp: Ditto.
gcc-6.2.1-2.fc24.x86_64
(gdb) backtrace 10^M
(gdb) FAIL: gdb.arch/i386-signal.exp: backtrace 10
(gdb) disas/s
Dump of assembler code for function main:
.../gdb/testsuite/gdb.arch/i386-signal.c:
30 {
0x000000000040057f <+0>: push %rbp
0x0000000000400580 <+1>: mov %rsp,%rbp
31 setup ();
0x0000000000400583 <+4>: callq 0x400590 <setup>
=> 0x0000000000400588 <+9>: mov $0x0,%eax
32 }
0x000000000040058d <+14>: pop %rbp
0x000000000040058e <+15>: retq
End of assembler dump.
The .exp patch is an obvious typo fix I think. The regex was written to
accept "ADDR in main" and I find it OK as checking .debug_line validity is not
the purpose of this testfile.
gcc-4.8.5-11.el7.x86_64 did not put the 'mov $0x0,%eax' instruction there at
all so there was no problem with .debug_line.
gdb/testsuite/ChangeLog
2016-10-05 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.arch/i386-signal.exp (backtrace 10): Fix#2 typo.
If the target doesn't support float, we don't run float complex types
tests.
gdb/testsuite:
2016-10-05 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (support_complex_tests): Return zero if
gdb_skip_float_test return true.
This patch adds a test to verify that events are sent properly to all
UIs when the user selection context (inferior, thread, frame) changes.
The goal of the C test file is to provide two threads that are stopped with the
same predictable backtrace (so that we can test frame switching). The barrier
helps us know when the child threads are started. Then, scheduler-locking is
used to bring each thread one by one to the position we expect them to be
during the test.
gdb/testsuite/ChangeLog:
YYYY-MM-DD Antoine Tremblay <antoine.tremblay@ericsson.com>
YYYY-MM-DD Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20487
* gdb.mi/user-selected-context-sync.exp: New file.
* gdb.mi/user-selected-context-sync.c: New file.
With this patch, when an inferior, thread or frame is explicitly
selected by the user, notifications will appear on all CLI and MI UIs.
When a GDB console is integrated in a front-end, this allows the
front-end to follow a selection made by the user ont he CLI, and it
informs the user about selection changes made behind the scenes by the
front-end.
This patch addresses PR gdb/20487.
In order to communicate frame changes to the front-end, this patch adds
a new field to the =thread-selected event for the selected frame. The
idea is that since inferior/thread/frame can be seen as a composition,
it makes sense to send them together in the same event. The vision
would be to eventually send the inferior information as well, if we find
that it's needed, although the "=thread-selected" event would be
ill-named for that job.
Front-ends need to handle this new field if they want to follow the
frame selection changes that originate from the console. The format of
the frame attribute is the same as what is found in the *stopped events.
Here's a detailed example for each command and the events they generate:
thread
------
1. CLI command:
thread 1.3
MI event:
=thread-selected,id="3",frame={...}
2. MI command:
-thread-select 3
CLI event:
[Switching to thread 1.3 ...]
3. MI command (CLI-in-MI):
thread 1.3
MI event/reply:
&"thread 1.3\n"
~"#0 child_sub_function () ...
=thread-selected,id="3",frame={level="0",...}
^done
frame
-----
1. CLI command:
frame 1
MI event:
=thread-selected,id="3",frame={level="1",...}
2. MI command:
-stack-select-frame 1
CLI event:
#1 0x00000000004007f0 in child_function...
3. MI command (CLI-in-MI):
frame 1
MI event/reply:
&"frame 1\n"
~"#1 0x00000000004007f9 in ..."
=thread-selected,id="3",frame={level="1"...}
^done
inferior
--------
Inferior selection events only go from the console to MI, since there's
no way to select the inferior in pure MI.
1. CLI command:
inferior 2
MI event:
=thread-selected,id="3"
Note that if the user selects an inferior that is not started or exited,
the MI doesn't receive a notification. Since there is no threads to
select, the =thread-selected event does not apply...
2. MI command (CLI-in-MI):
inferior 2
MI event/reply:
&"inferior 2\n"
~"[Switching to inferior 2 ...]"
=thread-selected,id="4",frame={level="0"...}
^done
Internal implementation detail: this patch makes it possible to suppress
notifications caused by a CLI command, like what is done in mi-interp.c.
This means that it's now possible to use the
add_com_suppress_notification function to register a command with some
event suppressed. It is used to implement the select-frame command in
this patch.
The function command_notifies_uscc_observer was added to extract
the rather complicated logical expression from the if statement. It is
also now clearer what that logic does: if the command used by the user
already notifies the user_selected_context_changed observer, there is
not need to notify it again. It therefore protects again emitting the
event twice.
No regressions, tested on ubuntu 14.04 x86 with target boards unix and
native-extended-gdbserver.
gdb/ChangeLog:
YYYY-MM-DD Antoine Tremblay <antoine.tremblay@ericsson.com>
YYYY-MM-DD Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20487
* NEWS: Mention new frame field of =thread-selected event.
* cli/cli-decode.c (add_cmd): Initialize c->suppress_notification.
(add_com_suppress_notification): New function definition.
(cmd_func): Set and restore the suppress_notification flag.
* cli/cli-deicode.h (struct cmd_list_element)
<suppress_notification>: New field.
* cli/cli-interp.c (cli_suppress_notification): New global variable.
(cli_on_user_selected_context_changed): New function.
(_initialize_cli_interp): Attach to user_selected_context_changed
observer.
* command.h (struct cli_suppress_notification): New structure.
(cli_suppress_notification): New global variable declaration.
(add_com_suppress_notification): New function declaration.
* defs.h (enum user_selected_what_flag): New enum.
(user_selected_what): New enum flag type.
* frame.h (print_stack_frame_to_uiout): New function declaration.
* gdbthread.h (print_selected_thread_frame): New function declaration.
* inferior.c (print_selected_inferior): New function definition.
(inferior_command): Remove printing of inferior/thread/frame switch
notifications, notify user_selected_context_changed observer.
* inferior.h (print_selected_inferior): New function declaration.
* mi/mi-cmds.c (struct mi_cmd): Add user_selected_context
suppression to stack-select-frame and thread-select commands.
* mi/mi-interp.c (struct mi_suppress_notification)
<user_selected_context>: Initialize.
(mi_user_selected_context_changed): New function definition.
(_initialize_mi_interp): Attach to user_selected_context_changed.
* mi/mi-main.c (mi_cmd_thread_select): Print thread selection reply.
(mi_execute_command): Handle notification suppression. Notify
user_selected_context_changed observer on thread change instead of printing
event directly. Don't send it if command already sends the notification.
(command_notifies_uscc_observer): New function.
(mi_cmd_execute): Don't handle notification suppression.
* mi/mi-main.h (struct mi_suppress_notification)
<user_selected_context>: New field.
* stack.c (print_stack_frame_to_uiout): New function definition.
(select_frame_command): Notify user_selected_context_changed
observer.
(frame_command): Call print_selected_thread_frame if there's no frame
change or notify user_selected_context_changed observer if there is.
(up_command): Notify user_selected_context_changed observer.
(down_command): Likewise.
(_initialize_stack): Suppress user_selected_context notification for
command select-frame.
* thread.c (thread_command): Notify
user_selected_context_changed if the thread has changed, print
thread info directly if it hasn't.
(do_captured_thread_select): Do not print thread switch event.
(print_selected_thread_frame): New function definition.
* tui/tui-interp.c (tui_on_user_selected_context_changed):
New function definition.
(_initialize_tui_interp): Attach to user_selected_context_changed
observer.
gdb/doc/ChangeLog:
PR gdb/20487
* gdb.texinfo (Context management): Update mention of frame
change notifications.
(gdb/mi Async Records): Document frame field in
=thread-select event.
* observer.texi (GDB Observers): New user_selected_context_changed
observer.
gdb/testsuite/ChangeLog:
PR gdb/20487
* gdb.mi/mi-pthreads.exp (check_mi_thread_command_set): Adapt
=thread-select-event check.
Regression: gdb --pid $(pidof qemu-system-x86_64) stopped working with gdb 7.11.1
https://sourceware.org/bugzilla/show_bug.cgi?id=20609
It was reported for qemu-system-x86_64 but it happens for any multithreaded
inferior with a JIT debugging hook.
136613ef0c6850427317e57be1b644080ff6decb is the first bad commit
Author: Pedro Alves <palves@redhat.com>
Fix PR gdb/19828: gdb -p <process from a container>: internal error
Message-ID: <cbdf2e04-4fa8-872a-2a23-08c9c1b26e00@redhat.com>
https://sourceware.org/ml/gdb-patches/2016-05/msg00450.html
jit_breakpoint_re_set() is specific by trying to insert a breakpoint into the
main executable, not into a shared library. During attachment GDB thinks it
needs to use 'breakpoint always-inserted' from
breakpoints_should_be_inserted_now() as a newly attached thread is
'thread_info->executing' due to 'lwp_info->must_set_ptrace_flags' enabled and
the task not yet stopped. This did not happen before the 'bad commit' above
which adds tracking of such thread.
GDB then fails to insert the breakpoints to invalid address as PIE executable
gets properly relocated during later phase of attachment. One can see in the
backtraces below:
-> jit_breakpoint_re_set_internal()
later:
-> svr4_exec_displacement()
One can suppress the initial breakpoint_re_set() call as there will be another
breakpoint_re_set() done from the final post_create_inferior() call in
setup_inferior().
BTW additionally 'threads_executing' cache bool is somehow stale (somewhere is
missing update_threads_executing()). I was trying to deal with that in my
first/second attempt below but in my final third attempt (attached) I have
left it as it is.
First attempt trying not to falsely require 'breakpoint always-inserted':
https://people.redhat.com/jkratoch/rhbz1375553-fix1.patch
Reduced first attempt:
https://people.redhat.com/jkratoch/rhbz1375553-fix2.patch
The third attempt suppresses breakpoint insertion until PIE executable gets
relocated by svr4_exec_displacement(). Applied.
gdb/ChangeLog
2016-09-29 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/20609 - attach of JIT-debug-enabled inf 7.11.1 regression
* exec.c (exec_file_locate_attach): Add parameter defer_bp_reset.
Use it.
* gdbcore.h (exec_file_locate_attach): Add parameter defer_bp_reset.
* infcmd.c (setup_inferior): Update caller.
* remote.c (remote_add_inferior): Likewise.
gdb/testsuite/ChangeLog
2016-09-29 Jan Kratochvil <jan.kratochvil@redhat.com>
PR gdb/20609 - attach of JIT-debug-enabled inf 7.11.1 regression
* gdb.base/jit-attach-pie.c: New file.
* gdb.base/jit-attach-pie.exp: New file.
If you run an infcall from the command line, and immediately after run
some other command, GDB incorrectly processes the other command before
the infcall finishes.
The problem is that the fix for PR gdb/20418 (Problems with
synchronous commands and new-ui, git 3eb7562a98) moved the
add_file_handler/delete_file_handler calls out of
target_terminal_$foo, and missed adjusting the infcall code.
gdb/ChangeLog:
2016-09-28 Pedro Alves <palves@redhat.com>
* infcall.c (run_inferior_call): Remove input from the event
loop while running the infcall.
gdb/testsuite/ChangeLog:
2016-09-28 Pedro Alves <palves@redhat.com>
* gdb.base/infcall-input.c: New file.
* gdb.base/infcall-input.exp: New file.
In commit 6423214f (testsuite: Don't use expect_background to reap
gdbserver), we override gdb_exit in lib/gdbserver-support.exp, so
that we can close gdbserver first. However, we don't close gdbserver
in mi_gdb_exit. This makes a problem in my aarch64 mulit-arch testing,
in which I run some mi tests, mi-watch.exp for example, in different
variations (aarch64 and arm),
Schedule of variations:
junor0-2
junor0-2-arm/-marm
junor0-2-arm/-mthumb
When the test is done in the first variation (aarch64), test case is
recompiled for arm, but GDBserver with aarch64 program is still
running. When the second variation is started, GDB loads arm program,
but GDBserver still loads aarch64 program because the old GDBserver
process is using it. We'll get,
47-target-select remote junor0-2:2350^M
&"warning: Selected architecture arm is not compatible with reported target architecture aarch64\n"^M
&"warning: Architecture rejected target-supplied description\n"
This patch fixes this problem by closing GDBserver in mi_gdb_exit.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Rename mi_gdb_exit.
(gdb_exit): Rename it to ...
(gdbserver_gdb_exit): ... Close GDBserver.
(gdb_exit): New proc, call gdbserver_gdb_exit.
(mi_gdb_exit): Likewise.
This patch is to make remote-gdbserver-on-localhost.exp use gdbserver-base
and remove duplicated code.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* boards/gdbserver-base.exp (gdb_server_prog): Set the absolute
path.
* boards/remote-gdbserver-on-localhost.exp: Use gdbserver-base.
Remove duplication.
In lib/gdbserver-support.exp, we rename gdb_exit to
gdbserver_orig_gdb_exit, but we check the existence gdbserver_gdb_exit.
We should check gdbserver_orig_gdb_exit instead. Looks it is a typo
or an oversight.
gdb/testsuite:
2016-09-22 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp: Check the existence of
gdbserver_orig_gdb_exit rather than gdbserver_gdb_exit.
ARC is a family of licensable processors developed by Synopsys.
This is an initial patch that doesn't yet support some of the features, that
are already available in Synopsys' fork of GDB, namely:
* longjmp support
* signal frame handling
* prologue analysis
* Linux targets support
* native Linux support
ARC cores are configurable and extensible, which means from debugger
perspective that some registers and debug capabilities are optional, therefore
it is up to the GDB stub to determine exact list of register available on
target and supply it to GDB via XML target descriptions. List of registers
that is known to GDB and is required is intentionally kept small to simplify
requirements to GDB stub and implementation of a GDB client.
gdb/ChangeLog:
* Makefile.in (ALL_TARGET_OBS): Add arc-tdep.o.
(HFILES_NO_SRCDIR): Add arc-tdep.h.
(ALLDEPFILES): Add arc-tdep.c.
* NEWS: Mention new ARC port.
* configure.tgt: Add ARC.
* arc-tdep.c: New file.
* arc-tdep.h: New file.
* features/Makefile (XMLTOC): Add arc-v2.xml and arc-arcompact.xml.
* features/arc-v2.xml: New file.
* features/arc-v2.c: New file (generated).
* features/arc-arcompact.xml: New file.
* features/arc-arcompact.c: New file (generated).
gdb/doc/ChangeLog:
* gdb.texinfo (Embedded Processors): Document ARC.
(Synopsys ARC): New section.
(Standard Target Features): Document ARC features.
(ARC Features): New section.
gdb/testsuite/ChangeLog:
* gdb.xml/tdesc-regs.exp: set core-regs for arc*-*-elf32.
This fixes PR gdb/20604. The bug here is that passing an invalid
expression to "quit" -- e.g., "quit()" -- causes gdb to enter a
non-functioning state.
The immediate problem is that quit_force resets the terminal before
evaluating the expression. However, it seemed to me that it doesn't
really make sense to pass the quit_force argument to kill_or_detach
(which passes it to to_detach), first because conflating the exit
status for "quit" and the signal to pass when detaching doesn't make
sense, and second because to_detach implementations generally only
accept a constant here, while "quit" accepts an expression. So, I
removed that.
As an aside, I think the "detach SIGNO" functionality is not
documented.
Built and regtested on x86-64 Fedora 24.
2016-09-21 Tom Tromey <tom@tromey.com>
PR gdb/20604:
* top.h (quit_force): Update.
* top.c (quit_force): Changed type of first argument. Don't
evaluate expression. Pass NULL to kill_or_detach.
* cli/cli-cmds.c (quit_command): Evaluate "args".
2016-09-21 Tom Tromey <tom@tromey.com>
PR gdb/20604:
* gdb.base/quit.exp: New file.
This patch adds a bunch of generated files to gdb's gitignore files.
There are still a bunch of "stamp" files that are not ignored, but I
think the rule for them should be put in the top-level gitignore.
Users and developers are encouraged to build out-of-tree, but some
people prefer the simplicity to build in-tree, so it should be useful
for them.
gdb/ChangeLog:
* .gitignore: Ignore more files.
* data-directory/.gitignore: Likewise.
gdb/doc/ChangeLog:
* .gitignore: New file.
gdb/gdbserver/ChangeLog:
* .gitinore: Ignore more files.
gdb/testsuite/ChangeLog:
* .gitignore: New file.
Correct a commit 2151ccc56c ("Always organize test artifacts in a
directory hierarchy") regression causing:
Running .../gdb/testsuite/gdb.arch/mips16-thunks.exp ...
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
gdb compile failed, Assembler messages:
Fatal error: can't create .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
gdb compile failed, mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-inmain.o: No such file or directory
mips-mti-linux-gnu-gcc: error: .../gdb/testsuite/gdb.arch/mips16-thunks-main.o: No such file or directory
UNSUPPORTED: gdb.arch/mips16-thunks.exp: No MIPS16 support in the toolchain.
by using `standard_output_file' to construct output file names
throughout.
gdb/testsuite/
* gdb.arch/mips16-thunks.exp: Use `standard_output_file'
throughout.
gcc-6.2.1-1.fc26.x86_64
gdb compile failed, /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected primary-expression before 'int'
decltype(int x)
^~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:10: error: expected ')' before 'int'
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:40:1: error: expected unqualified-id before 'decltype'
decltype(int x)
^~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc: In function 'int main(int, char**)':
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/casts.cc:59:14: error: expected primary-expression before 'decltype'
double y = decltype(2);
^~~~~~~~
'decltype' is a registered keyword since C++11 which is now a default for GCC.
On Thu, 15 Sep 2016 14:06:56 +0200, Pedro Alves wrote:
Seems to be exercising the FLAG_SHADOW bits:
...
{"__typeof__", TYPEOF, OP_TYPEOF, 0 },
{"__typeof", TYPEOF, OP_TYPEOF, 0 },
{"typeof", TYPEOF, OP_TYPEOF, FLAG_SHADOW },
{"__decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX },
{"decltype", DECLTYPE, OP_DECLTYPE, FLAG_CXX | FLAG_SHADOW },
...
/* This is used to associate some attributes with a token. */
enum token_flag
{
...
/* If this bit is set, the token is conditional: if there is a
symbol of the same name, then the token is a symbol; otherwise,
the token is a keyword. */
FLAG_SHADOW = 2
};
So perhaps a better fix is to move that particular test to a
separate testcase that force-compiles with -std=c++03.
gdb/testsuite/ChangeLog
2016-09-16 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.cp/casts.cc (decltype): Move it ...
(main): ... with its call to ...
* gdb.cp/casts03.cc: ... a new file.
* gdb.cp/casts.exp: Add new file casts03.cc, move decltype test to it.
gcc-6.2.1-1.fc26.x86_64
g++ -std=c++03:
no warnings
g++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:0:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:34: error: ‘constexpr’ needed for in-class initialization of static
data member ‘const float gnu_obj_4::somewhere’ of non-integral type [-fpermissive]
static const float somewhere = 3.14159;
^~~~~~~
clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
1 warning generated.
clang++ -std=c++11:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: error: in-class initializer for static data member of type 'const
float' requires 'constexpr' specifier [-Wstatic-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:3: note: add 'constexpr'
static const float somewhere = 3.14159;
^
constexpr
1 error generated.
OK for check-in?
After the fix out of the 4 combinations above only this one remains non-empty:
clang++:
In file included from /home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.cc:79:
/home/jkratoch/redhat/gdb-clean/gdb/testsuite/gdb.cp/m-static.h:9:22: warning: in-class initializer for static data member of type 'const
float' is a GNU extension [-Wgnu-static-float-init]
static const float somewhere = 3.14159;
^ ~~~~~~~
1 warning generated.
On Thu, 15 Sep 2016 15:10:50 +0200, Pedro Alves wrote:
Hmm, OK, now that I read the test, I think you were right in trying to
keep it safe, actually. The .exp file has:
if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.everywhere" "\\$\[0-9\].* = 317" "static const int initialized in class definition"
if { $non_dwarf } { setup_xfail *-*-* }
gdb_test "print test4.somewhere" "\\$\[0-9\].* = 3.14\[0-9\]*" "static const float initialized in class definition"
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Added by this:
https://sourceware.org/bugzilla/show_bug.cgi?id=11702https://sourceware.org/ml/gdb-patches/2010-06/msg00677.htmlhttps://sourceware.org/ml/gdb-patches/2010-06/txt00011.txt
So the new patch would make that highlighted tested above not
test what its test message says it is testing.
So I now think your original patch is better. Please push
that one instead.
gdb/testsuite/ChangeLog
2016-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.cp/m-static.h (gnu_obj_4::somewhere): Use constexpr for C++11.
* gdb.arch/powerpc-power.s: Update Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
There were always various problems with compatibility with ccache:
https://bugzilla.redhat.com/show_bug.cgi?id=488863https://bugzilla.redhat.com/show_bug.cgi?id=759592https://sourceware.org/ml/gdb-patches/2009-02/msg00397.html
IMO in a summary ccache finds more a benefit of faster compilation despite the
debug info is no longer exactly the same (as without ccache).
Although for example in this case ccache helped to find a real GDB bug:
https://sourceware.org/ml/gdb-patches/2015-01/msg00497.html
For the GDB testcases ccache has (IMO) no real performance advantage and it
just brings heisenbugs - false FAILs - from time to time:
Breakpoint 1, main () at gdb/testsuite/gdb.base/vdso-warning.c:21^M
21 return 0;^M
(gdb) PASS: gdb.base/vdso-warning.exp: run: startup
->
Breakpoint 1, main () at gdb/testsuite/gdb.base/hbreak-unmapped.c:21^M
21 return 0;^M
(gdb) FAIL: gdb.base/vdso-warning.exp: run: startup
So I find most safe and easy to just disable ccache for all testsuites.
gdb/testsuite/ChangeLog
2016-09-15 Jan Kratochvil <jan.kratochvil@redhat.com>
* lib/future.exp: Set CCACHE_DISABLE, clear CCACHE_NODISABLE.
GCC 6's ICF optimization pass is making the declaration of 'm1' and
'm2', on gdb.base/stap-probe.c, to be unified. However, this leads to
only one instance of the probe 'two' being created, which causes a
failure on the testsuite (which expects a multi-location breakpoint to
be inserted on the probe).
This patch fixes this failure by declaring a dummy variable on 'm1',
and using it as an argument to m1's version of probe 'two'. Since we
do not care about the contents of the functions nor about the
arguments of each probe 'two', this is OK.
gdb/testsuite/ChangeLog:
2016-09-11 Sergio Durigan Junior <sergiodj@redhat.com>
Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/stap-probe.c (m1): New variable 'dummy', necessary to
make m1's definition to be different from m2's. Use 'dummy' as an
argument for probe 'two'.
On various GNU Elf architectures, including AArch64, ARM, s390/s390x,
ppc32/64, and sparc32/64, the dynamic loader passes HWCAP as a parameter
to each ifunc resolver. Currently there is an open glibc Bugzilla that
requests this to be generalized to all architectures:
https://sourceware.org/bugzilla/show_bug.cgi?id=19766
And various ifunc resolvers already rely on receiving HWCAP. Currently
GDB always calls an ifunc resolver without any arguments; thus the
resolver may receive garbage, and based on that, the resolver may decide
to return a function that is not suited for the given platform.
This patch always passes HWCAP to ifunc resolvers, even on systems where
the dynamic loader currently behaves otherwise. The rationale is
that (1) the dynamic loader may get adjusted on those systems as well in
the future; (2) passing an unused argument should not cause a problem
with existing resolvers; and (3) the logic is much simpler without such
a distinction.
gdb/ChangeLog:
* elfread.c (auxv.h): New include.
(elf_gnu_ifunc_resolve_addr): Pass HWCAP to ifunc resolver.
gdb/testsuite/ChangeLog:
* gdb.base/gnu-ifunc-lib.c (resolver_hwcap): New external
variable declaration.
(gnu_ifunc): Add parameter hwcap. Store it in resolver_hwcap.
* gdb.base/gnu-ifunc.c (resolver_hwcap): New global variable.
* gdb.base/gnu-ifunc.exp: Add test to verify that the resolver
received HWCAP as its argument.
I noticed that if input is already pending on the new-ui TTY, gdb
internal-errors.
E.g., create /dev/pts/2, and type anything there (even just <return>
is sufficient).
Now start GDB creating a new UI on that TTY, while at the same time,
running a synchronous execution command. Something like:
$ gdb program -ex "new-ui console /dev/pts/2" -ex "start"
Back on /dev/pts/2, we get:
(gdb) .../src/gdb/event-top.c:360: internal-error: double prompt
A problem internal to GDB has been detected,
further debugging may prove unreliable.
While the main UI was waiting for "start" to finish, gdb kepts pumping
events, including the input fd of the extra console. The problem is
that stdin_event_handler doesn't restore the current UI back to what
it was, assuming that it's only ever called from the top level event
loop. However, in this case, it's being called from the nested event
loop from within maybe_wait_sync_command_done.
When finally the "start" command is done, we reach the code that
prints the prompt in the main UI, just before starting the main event
loop. Since now the current UI is pointing at the extra console (by
mistake), we find ourselves printing a double prompt on the extra
console. This is caught by the assertion that fails, as shown above.
Since other event handlers also don't restore the UI (e.g., signal
event handlers), I think it's better if whatever is pumping events to
take care to restore the UI, if it cares. That's what this patch
does. New test included.
gdb/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* top.c (wait_sync_command_done): Don't assume current_ui doesn't
change across events. Restore the current UI before returning.
(gdb_readline_wrapper): Restore the current UI before returning.
gdb/testsuite/ChangeLog:
2016-09-06 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui-pending-input.c: New file.
* gdb.base/new-ui-pending-input.exp: New file.
* gdb.exp (clear_gdb_spawn_id): New procedure.
(with_spawn_id): Check whether gdb_spawn_id exists before
referencing it. If gdb_spawn_id didn't exist on entry, clear it
on exit.
Now that all the prerequisites are in place, this commit finally adds support
for handling the __float128 type on Intel and Power, by providing appropriate
platform-specific versions of the floatformat_for_type callback.
Since at this point we do not yet have any indication in the debug info to
distinguish different floating-point formats of the same length, we simply
use the type name as hint. Types named "__float128" get the IEEE format.
In addition to handling "__float128" itself, we also recognize "_Float128"
and (on Power) "_Float64x", as well as the complex versions of those.
(As pointed out by Joseph Myers, starting with GCC 7, __float128 is just
a typedef for _Float128 -- but it's good to handle this anyway.)
A new test case does some simple verification that the format is decoded
correctly, using both __float128 and "long double" to make sure using both
in the same file still works. Another new test verifies handling of the
_FloatN and _FloatNx types supported by GCC 7, as well as the complex
versions of those types.
Note that this still only supports basic format decoding and encoding.
We do not yet support the GNU extension 'g' suffix for __float128 constants.
In addition, since all *arithmetic* on floating-point values is still
performed in native host "long double" arithmetic, if that format is not
able to encode all target __float128 values, we may get incorrect results.
(To fix this would require implementing fully synthetic target floating-
point arithmetic along the lines of GCC's real.c, presumably using MPFR.)
gdb/ChangeLog:
* i386-tdep.c (i386_floatformat_for_type): New function.
(i386_gdbarch_init): Install it.
* ppc-linux-tdep.c (ppc_floatformat_for_type): New function.
(ppc_linux_init_abi): Install it.
gdb/testsuite/ChangeLog:
* gdb.base/float128.c: New file.
* gdb.base/float128.exp: Likewise.
* gdb.base/floatn.c: Likewise.
* gdb.base/floatn.exp: Likewise.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
Now that init_type no longer takes a FLAGS argument, there is no user of
the TYPE_FLAGS_... enum values left. This commit removes them (and all
references to them in comments as well).
This is mostly a no-op, except for a change to the Python type printer,
which attempted to use them before. (As best as I can tell, this wasn't
really needed anyway, since it was only used to pretty-print type
*instance* flags, which only use the instance flags.)
gdb/ChangeLog:
* gdbtypes.h (enum type_flag_value): Remove.
Remove references to TYPE_FLAG_... in comments throughout.
* gdbtypes.c (recursive_dump_type): Do not print TYPE_FLAG_...
flags, print the corresponding TYPE_... access macro names.
Remove references to TYPE_FLAG_... in comments throughout.
* infcall.c: Remove references to TYPE_FLAG_... in comments.
* valprint.c: Likewise.
* gdb-gdb.py (class TypeFlag): No longer consider TYPE_FLAG_...
values, only TYPE_INSTANCE_FLAG_... values.
(class TypeFlagsPrinter): Likewise.
gdb/testsuite/ChangeLog:
* gdb.cp/hang.exp: Remove reference to TYPE_FLAG_STUB in comment.
Signed-off-by: Ulrich Weigand <ulrich.weigand@de.ibm.com>
This fixes the problem exercised by Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
This was originally exposed by the OpenJDK Python-based unwinder.
If an unwinder attempts to call parse_and_eval from within its
sniffing method, GDB's unwinding machinery enters infinite recursion.
However, parse_and_eval is a pretty reasonable thing to call, because
Python/Scheme-based unwinders will often need to read globals out of
inferior memory. The recursion happens because:
- get_current_frame() is called soon after the target stops.
- current_frame is NULL, and so we unwind it from the sentinel frame
(which is special and has level == -1).
- We reach get_prev_frame_if_no_cycle, which does cycle detection
based on frame id, and thus tries to compute the frame id of the new
frame.
- Frame id computation requires an unwinder, so we go through all
unwinder sniffers trying to see if one accepts the new frame (the
current frame).
- the unwinder's sniffer calls parse_and_eval().
- parse_and_eval depends on the selected frame/block, and if not set
yet, the selected frame is set to the current frame.
- get_current_frame () is called again. current_frame is still NULL,
so ...
- recurse forever.
In Kevin's test at:
https://sourceware.org/ml/gdb-patches/2016-08/msg00216.html
gdb doesn't recurse forever simply because the Python unwinder
contains code to detect and stop the recursion itself. However, GDB
goes downhill from here, e.g., by showing the sentinel frame as
current frame (note the -1):
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
That "-1" frame level comes from this:
if (catch_exceptions (current_uiout, unwind_to_current_frame,
sentinel_frame, RETURN_MASK_ERROR) != 0)
{
/* Oops! Fake a current frame? Is this useful? It has a PC
of zero, for instance. */
current_frame = sentinel_frame;
}
which is bogus. It's never correct to set the current frame to the
sentinel frame. The only reason this has survived so long is that
getting here normally indicates something wrong has already happened
before and we fix that. And this case is no exception -- it doesn't
really matter how precisely we managed to get to that bogus code (it
has to do with the the stash), because anything after recursion
happens is going to be invalid.
So the fix is to avoid the recursion in the first place.
Observations:
#1 - The recursion happens because we try to do cycle detection from
within get_prev_frame_if_no_cycle. That requires computing the
frame id of the frame being unwound, and that itself requires
calling into the unwinders.
#2 - But, the first time we're unwinding from the sentinel frame,
when we reach get_prev_frame_if_no_cycle, there's no frame chain
at all yet:
- current_frame is NULL.
- the frame stash is empty.
Thus, there's really no need to do cycle detection the first time we
reach get_prev_frame_if_no_cycle, when building the current frame.
So we can break the recursion by making get_current_frame call a
simplified version of get_prev_frame_if_no_cycle that results in
setting the current_frame global _before_ computing the current
frame's id.
But, we can go a little bit further. As there's really no reason
anymore to compute the current frame's frame id immediately, we can
defer computing it to when some caller of get_current_frame might need
it. This was actually how the frame id was computed for all frames
before the stash-based cycle detection was added. So in a way, this
patch reintroduces the lazy frame id computation, but unlike before,
only for the case of the current frame, which turns out to be special.
This lazyness, however, requires adjusting
gdb.python/py-unwind-maint.exp, because that assumes unwinders are
immediately called as side effect of some commands. I didn't see a
need to preserve the behavior expected by that test (all it would take
is call get_frame_id inside get_current_frame), so I adjusted the
test.
gdb/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* frame.c (get_frame_id): Compute the frame id if not computed
yet.
(unwind_to_current_frame): Delete.
(get_current_frame): Use get_prev_frame_always_1 to get the
current frame and assert that that always succeeds.
(get_prev_frame_if_no_cycle): Skip cycle detection if returning
the current frame.
gdb/testsuite/ChangeLog:
2016-09-05 Pedro Alves <palves@redhat.com>
PR backtrace/19927
* gdb.python/py-unwind-maint.exp: Adjust tests to not expect that
unwinders are immediately called as side effect of "source" or
"disable unwinder" commands.
* gdb.python/py-recurse-unwind.exp: Remove setup_kfail calls.
return-nodebug.exp does the test for various types, but we shouldn't
test with floating point type if gdb_skip_float_test returns true.
gdb/testsuite:
2016-09-02 Yao Qi <yao.qi@linaro.org>
* gdb.base/return-nodebug.exp: Skip the test if skip_float_test
is true and $type is "float" or "double".
We recently found a ARM kernel ptrace bug
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-May/431962.html
Details can be found in the comment in gdb_skip_float_test. We can
skip floating point tests if the kernel bug is detected.
This patch adds more code in gdb_skip_float_test to detect the broken
ptrace on arm-linux. Such detection should be done at the beginning
of the test, because it starts a fresh GDB, so change the test cases
to invoke gdb_skip_float_test at the beginning of test, and use its
return value afterwards.
Since gdb_skip_float_test becomes a gdb_caching_proc, so it can't
have an argument, this patch also removes argument "msg", which isn't
useful.
gdb/testsuite:
2016-09-02 Yao Qi <yao.qi@linaro.org>
* gdb.arch/arm-neon.exp: Skip it if gdb_skip_float_test returns
true.
* gdb.base/call-ar-st.exp: Invoke gdb_skip_float_test.
* gdb.base/call-rt-st.exp: Likewise.
* gdb.base/call-sc.exp: Invoke gdb_skip_float_test and use its
return value instead of gdb,skip_float_test.
* gdb.base/callfuncs.exp: Invoke gdb_skip_float_test.
(do_function_calls): Use its return value instead of
gdb,skip_float_test.
* gdb.base/finish.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/return.exp: Likewise.
* gdb.base/return2.exp: Likewise.
* gdb.base/varargs.exp: Likewise.
* lib/gdb.exp (gdb_skip_float_test): Change it to
gdb_caching_proc. Detect the broken ptrace on arm-linux.
This inserts missing parentheses in the calculation of the comparison
result between two different inferior numbers. The problem was found by
Philipp Rudo.
gdb/ChangeLog:
* thread.c (tp_array_compar): Insert missing parentheses.
gdb/testsuite/ChangeLog:
* gdb.multi/tids.exp: Test "thread apply all".
This test case verifies that GDB will not attempt to invoke a python
unwinder recursively.
At the moment, the behavior exhibited by GDB looks like this:
(gdb) source py-recurse-unwind.py
Python script imported
(gdb) b ccc
Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23.
(gdb) run
Starting program: py-recurse-unwind
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
TestUnwinder: Recursion detected - returning early.
Breakpoint 1, ccc (arg=<unavailable>) at py-recurse-unwind.c:23
23 }
(gdb) bt
#-1 ccc (arg=<unavailable>) at py-recurse-unwind.c:23
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[I've shortened pathnames for easier reading.]
The desired / expected behavior looks like this:
(gdb) source py-recurse-unwind.py
Python script imported
(gdb) b ccc
Breakpoint 1 at 0x4004bd: file py-recurse-unwind.c, line 23.
(gdb) run
Starting program: py-recurse-unwind
Breakpoint 1, ccc (arg=789) at py-recurse-unwind.c:23
23 }
(gdb) bt
#0 ccc (arg=789) at py-recurse-unwind.c:23
#1 0x00000000004004d5 in bbb (arg=456) at py-recurse-unwind.c:28
#2 0x00000000004004ed in aaa (arg=123) at py-recurse-unwind.c:34
#3 0x00000000004004fe in main () at py-recurse-unwind.c:40
Note that GDB's problems go well beyond the fact that it invokes the
unwinder recursively. In the process it messes up some internal state
(the frame stash) leading to display of (only) the sentinel frame in
the backtrace.
gdb/testsuite/ChangeLog:
* gdb.python/py-recurse-unwind.c: New file.
* gdb.python/py-recurse-unwind.py: New file.
* gdb.python/py-recurse-unwind.exp: New file.
This patch allows the user to set the inferior-tty to "empty", in order
to come back to the default behaviour of using the same tty as gdb is
using.
This is already supported in MI (and tested in gdb.mi/mi-basics.exp).
I added a new test, set-inferior-tty.exp, where I test only the setting
and unsetting of the parameter. It would be nice to actually test that
the inferior output properly goes to the separate tty, but that will be
for another day.
gdb/ChangeLog:
* infcmd.c (set_inferior_io_terminal): Set inferior terminal to
NULL if terminal_name is an empty string.
(_initialize_infcmd): Make the argument of "set inferior-tty"
optional, mention it in the help doc.
gdb/doc/ChangeLog:
* gdb.texinfo (Input/Output): Mention possibility to unset
inferior-tty.
gdb/testsuite/ChangeLog:
* gdb.base/set-inferior-tty.exp: New file.
* gdb.base/set-inferior-tty.c: New file.
This patch fixes a problem that problem triggers if you start an
inferior, e.g., with the "start" command, in a UI created with the
new-ui command, and then run a foreground execution command in the
main UI. Once the program stops for the latter command, typing in the
main UI no longer echoes back to the user.
The problem revolves around this:
- gdb_has_a_terminal computes its result lazily, on first call.
that is what saves gdb's initial main UI terminal state (the UI
associated with stdin):
our_terminal_info.ttystate = serial_get_tty_state (stdin_serial);
This is the state that target_terminal_ours() restores.
- In this scenario, the gdb_has_a_terminal function happens to be
first ever called from within the target_terminal_init call in
startup_inferior:
(top-gdb) bt
#0 gdb_has_a_terminal () at src/gdb/inflow.c:157
#1 0x000000000079db22 in child_terminal_init_with_pgrp () at src/gdb/inflow.c:217
[...]
#4 0x000000000065bacb in target_terminal_init () at src/gdb/target.c:456
#5 0x00000000004676d2 in startup_inferior () at src/gdb/fork-child.c:531
[...]
#7 0x000000000046b168 in linux_nat_create_inferior () at src/gdb/linux-nat.c:1112
[...]
#9 0x00000000005f20c9 in start_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:657
If the command to start the inferior is issued on the main UI, then
readline will have deprepped the terminal when we reach the above, and
the problem doesn't appear.
If however the command is issued on a non-main UI, then when we reach
that gdb_has_a_terminal call, the main UI's terminal state is still
set to whatever readline has sets it to in rl_prep_terminal, which
happens to have echo disabled. Later, when the following synchronous
execution command finishes, we'll call target_terminal_ours to restore
gdb's the main UI's terminal settings, and that restores the terminal
state with echo disabled...
Conceptually, the fix is to move the gdb_has_a_terminal call earlier,
to someplace during GDB initialization, before readline/ncurses have
had a chance to change terminal settings. Turns out that
"set_initial_gdb_ttystate" is exactly such a place.
I say conceptually, because the fix actually inlines the
gdb_has_a_terminal part that saves the terminal state in
set_initial_gdb_ttystate and then simplifies gdb_has_a_terminal, since
there's no point in making gdb_has_a_terminal do lazy computation.
gdb/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* inflow.c (our_terminal_info, initial_gdb_ttystate): Update
comments.
(enum gdb_has_a_terminal_flag_enum, gdb_has_a_terminal_flag):
Delete.
(set_initial_gdb_ttystate): Record our_terminal_info here too,
instead of ...
(gdb_has_a_terminal): ... here. Reimplement in terms of
initial_gdb_ttystate. Make static.
* terminal.h (gdb_has_a_terminal): Delete declaration.
(set_initial_gdb_ttystate): Add comment.
* top.c (show_interactive_mode): Use input_interactive_p instead
of gdb_has_a_terminal.
gdb/testsuite/ChangeLog:
2016-08-23 Pedro Alves <palves@redhat.com>
PR gdb/20494
* gdb.base/new-ui-echo.c: New file.
* gdb.base/new-ui-echo.exp: New file.
Hi,
I happen to see gdbserver is spawned like this in gdb.log,
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
spawn /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.s
erver/connect-stopped-target/connect-stopped-target /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/connect-stopped-target/connect-stopped-t
arget
as we can see, there are two instances of connect-stopped-target or
connect-stopped-target in the command line spawning gdbserver, but
none of these gets parameters from command line. In these two
tests, gdbserver is spawned via "gdbserver_spawn ${binfile}". However,
the argument of gdbserver_spawn is the argument passed the child
inferior, not the program itself.
# Start a gdbserver process running SERVER_EXEC, and connect GDB
# to it. CHILD_ARGS are passed to the inferior.
#
# Returns the target protocol and socket to connect to.
proc gdbserver_spawn { child_args } {
set target_exec [gdbserver_download_current_prog]
GDBserver gets the program via last_loaded_file, which is set by
gdb_file_cmd. In each test, we don't need to pass ${binfile}.
gdb/testsuite:
2016-08-23 Yao Qi <yao.qi@linaro.org>
* gdb.server/connect-stopped-target.exp (do_test): Pass "" to
gdbserver_spawn.
* gdb.server/connect-without-multi-process.exp (do_test):
Likewise.
Remote testing isn't considered in signals-state-child.exp, so the it
fails like
shell diff -s /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/gdb.txt^M
diff: /scratch/yao/gdb/build-git/aarch64-linux-gnu/gdb/testsuite/outputs/gdb.base/signals-state-child/standalone.txt: No such file or directory^M
(gdb) FAIL: gdb.base/signals-state-child.exp: signals states are identical
This patch is to fix it.
gdb/testsuite:
2016-08-23 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.exp: Set variables gdb_txt and
standalone_txt. Delete gdb_txt and standalone_txt on host
and target. Spawn the binary on target. Copy files from
target to host.
Loading a core dump that was either generated on a system running
pristine glibc master, or on a Fedora/RHEL system with LD_DEBUG=unused
set in the environment, solib-svr4.c:svr4_current_sos fails to filter
out the vDSO, resulting in:
(gdb) core-file corefile.core^M
[New LWP 2362]^M
warning: Could not load shared library symbols for linux-vdso.so.1.^M
Do you need "set solib-search-path" or "set sysroot"?^M
Core was generated by `build-gdb/gdb/testsuite/outputs/gdb.base/corefile/'.^M
...
The problem is that gdbarch_vsyscall_range does not support core
inferiors at all.
When live debugging, we're finding the vDSO's start address with
auxv/AT_SYSINFO_EHDR, and then we find the vDSO's size by look for the
corresponding mapping, by parsing /proc/PID/maps. When debugging a
core dump, we can also determine the starting address from
auxv/AT_SYSINFO_EHDR. However, we obviously can't read the core
mappings out of the host's /proc. But we can instead look for a
corresponding load segment in the core's bfd.
gdb/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* linux-tdep.c (linux_vsyscall_range_raw): For core inferiors,
find the vDSO's start address with AT_SYSINFO_EHDR too, and
determine the vDSO's size by finding the PT_LOAD segment that
matches AT_SYSINFO_EHDR.
gdb/testsuite/ChangeLog:
2016-08-22 Pedro Alves <palves@redhat.com>
PR gdb/20505
* gdb.base/vdso-warning.exp: Test core dumps too. Use
with_test_prefix. Factor out bits to ...
(test_no_vdso): ... this new procedure.
This patch fixes an issues with six test suite expect files that do not
run correctly when the test suite is not built in the source directory. The
issue is these tests are not using the current "standard_testfile" call
but rather using the older set command to initialize the "testfile",
"srcfile" and "binprefix" variables or are missing the set for the
"binprefix" variable.
-----------------------------------------------
gdb/testsuite/ChangeLog
2016-08-19 Carl Love <cel@us.ibm.com>
* gdb.arch/altivec-regs.exp: Use standard_testfile instead of
maintaining separate logic for constructing the output path.
* gdb.arch/powerpc-d128-regs.exp: Likewise.
* gdb.arch/ppc-dfp.exp: Likewise.
* gdb.arch/ppc-fp.exp: Likewise.
* gdb.arch/vsx-regs.exp: Likewise.
* gdb.arch/altivec-abi.exp: Likewise, plus added local variable
binprefix for generating the additional binary files.
gdb.trace/mi-trace-frame-collected.exp has a couple failures on x32:
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
gdb.log:
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: live: -trace-frame-collected (register)
[...]
-trace-frame-collected
^done,explicit-variables=[{name="gdb_char_test",value="0 '\\000'"}],computed-expressions=[],registers=[{number="16",value="0x4004dc"},{number="204",value="0x4004dc"}],tvars
=[],memory=[{address="0x00601060",length="1"}]
(gdb)
FAIL: gdb.trace/mi-trace-frame-collected.exp: tfile: -trace-frame-collected (register)
This test only collects the PC, and thus expects to only see one
register in the output of -trace-frame-collected. However, while on
the 64-bit ABI gdb only exposes 64-bit $pc/$rip (register 16 above),
on x32, GDB exposes 32-bit $eip as well, as a pseudo-register
(register 204 above). Thus, collecting $pc/$rip automatically always
collects $eip as well.
gdb/testsuite/ChangeLog:
2016-08-19 Pedro Alves <palves@redhat.com>
* gdb.trace/mi-trace-frame-collected.exp
(test_trace_frame_collected): On x32, expect two registers.
gdb/ChangeLog:
* MAINTAINERS (Write After Approval): Add "Carl Love".
gdb/testsuite/ChangeLog:
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
The GDB testsuite reports 5 test failures on Power 7 instructions.
Additionally the ppc test is missing the new Power 9 instructions as
well as a large number of older instructions. Additionally, some
instruction names have changed or been deleted. This patch
fixes the test failures and completely updates the test to make it
consistent with the supported Power 9 instructions listed in:
gas/testsuite/gas/ppc/power7.d
gas/testsuite/gas/ppc/power8.d
gas/testsuite/gas/ppc/power9.d
gas/testsuite/gas/ppc/altivec.d
gas/testsuite/gas/ppc/altivec2.d
gas/testsuite/gas/ppc/altivec3.d
gas/testsuite/gas/ppc/vsx.d
gas/testsuite/gas/ppc/vsx2.d
gas/testsuite/gas/ppc/vsx3.d
-----------------------------------------------------
gdb/testsuite/ChangeLog
2016-08-18 Carl Love <cel@us.ibm.com>
* gdb.arch/powerpc-power.s: Add new Power9 instruction tests
and sync up the test with tests in gas/testsuite/gas/ppc.
* gdb.arch/powerpc-power.exp: Likewise.
This error message should not contain the word symbol:
(gdb) remove-inferiors 1
Warning: Can not remove current symbol inferior 1.
gdb/ChangeLog:
* inferior.c (remove_inferior_command): Fix error message.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp (test_remove_inferiors): Fix
expected error message.
I noticed that the remove-inferiors command was not tested, and as I am
doing some changes related to the user selection, I want to make sure I
don't break it. For example, I want to make sure it's not possible to
remove the current inferior.
gdb/testsuite/ChangeLog:
* gdb.multi/remove-inferiors.exp: New file.
* gdb.multi/remove-inferiors.c: New file.
I see the following warning when running signals-state-child.exp.
gdb/testsuite/gdb.base/signals-state-child.c:77:4: warning: too many arguments for format [-Wformat-extra-args]
fprintf (out, "sigaction={sa_handler=", i);
^
this patch is to remove the argument from fprintf.
gdb/testsuite:
2016-08-12 Yao Qi <yao.qi@linaro.org>
* gdb.base/signals-state-child.c (main): Remove "i" from fprintf's
argument list.
Right after a fork is detected, we detach breakpoints from the child
(detach_breakpoints), which calls into target_remove_breakpoint with
inferior_ptid pointing at the child process, but leaves the breakpoint
marked inserted (in the parent).
The problem is that record-full.c always deletes all knowledge of the
breakpoint. Then when we later really delete the breakpoint from the
parent, we fail the assertion, since the breakpoint is unexpectedly
not found in the record-full.c breakpoint table.
The fix is simply to not forget about the breakpoint if we're
detaching it from a fork child.
gdb/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* record-full.c (record_full_remove_breakpoint): Don't remove the
breakpoint from the record_full_breakpoints VEC if we're detaching
the breakpoint from a fork child.
gdb/testsuite/ChangeLog:
2016-08-10 Pedro Alves <palves@redhat.com>
PR gdb/19187
* gdb.reverse/waitpid-reverse.exp: Add comment and remove
setup_kfails.
When executing commands on a secondary UI running the MI interpreter,
some commands that should be synchronous are not. MI incorrectly
continues processing input right after the synchronous command is
sent, before the target stops.
The problem happens when we emit MI async events (=library-loaded,
etc.), and we go about restoring the previous terminal state, we end
up calling target_terminal_ours, which incorrectly always installs the
current UI's input_fd in the event loop... That is, code like this:
old_chain = make_cleanup_restore_target_terminal ();
target_terminal_ours_for_output ();
fprintf_unfiltered (mi->event_channel, "library-loaded");
...
do_cleanups (old_chain);
The fix is to move the add_file_handler/delete_file_handler calls out
of target_terminal_$foo, making these completely no-ops unless called
with the main UI as current UI.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/20418
* event-top.c (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New functions.
(async_enable_stdin): Register input in the event loop.
(async_disable_stdin): Unregister input from the event loop.
(gdb_setup_readline): Register input in the event loop.
* infrun.c (check_curr_ui_sync_execution_done): Register input in
the event loop.
* target.c (target_terminal_inferior): Don't unregister input from
the event loop.
(target_terminal_ours): Don't register input in the event loop.
* target.h (target_terminal_inferior)
(target_terminal_ours_for_output, target_terminal_ours): Update
comments.
* top.h (ui_register_input_event_handler)
(ui_unregister_input_event_handler): New declarations.
* utils.c (ui_unregister_input_event_handler_cleanup)
(prepare_to_handle_input): New functions.
(defaulted_query, prompt_for_continue): Use
prepare_to_handle_input.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
Simon Marchi <simon.marchi@ericsson.com>
PR gdb/20418
* gdb.mi/new-ui-mi-sync.c, gdb.mi/new-ui-mi-sync.exp: New files.
* lib/mi-support.exp (mi_expect_interrupt): Remove anchors.
gdb 7.11 introduced an MI regression: a failing MI sync execution
command misses printing the MI prompt, and then all subsequent command
miss it too:
$ gdb-7.11.1 -i=mi
[...]
p 1
&"p 1\n"
~"$1 = 1"
~"\n"
^done
(gdb) <<< prompted ok
-exec-continue
^error,msg="The program is not being run." <<< missing prompt after this
print 1
&"print 1\n"
~"$2 = 1"
~"\n"
^done <<< missing prompt after this
gdb 7.10.1 behaved correctly, even with "set mi-async on":
-exec-continue
^error,msg="The program is not being run."
(gdb) <<< prompted ok
etc.
Bisecting points at:
commit 0b333c5e7d
Author: Pedro Alves <palves@redhat.com>
Date: Wed Sep 9 18:23:23 2015 +0100
Merge async and sync code paths some more
[...]
The problem is that when an exception is thrown, we leave the prompt
state set to PROMPT_BLOCKED, and then mi_execute_command_input_handler
doesn't print the prompt. It used to work because before that patch,
we happened to skip disabling stdin if the current target didn't do
async (which it never does before execution).
I was surprised to find that this bug isn't caught by the testsuite,
so I made a thorough test that tests all combinations of pairs of:
- a failing synchronous execution command
- a failing non-execution command
- a non-failing command
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* mi/mi-main.c (mi_execute_command): Enable input and set prompt
state to PROMPT_NEEDED.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR mi/20431
* gdb.mi/mi-cmd-error.exp: New file.
gdb's (or gdbserver's) own signal handling should not interfere with
the signal dispositions their spawned children inherit. However, it
currently does. For example, some paths in gdb cause SIGPIPE to be
set to SIG_IGN, and as consequence, the child starts with SIGPIPE to
set to SIG_IGN too, even though gdb was started with SIGPIPE set to
SIG_DFL.
This is because the exec family of functions does not reset the signal
disposition of signals that are set to SIG_IGN:
http://pubs.opengroup.org/onlinepubs/7908799/xsh/execve.html
Signals set to the default action (SIG_DFL) in the calling process
image are set to the default action in the new process
image. Signals set to be ignored (SIG_IGN) by the calling process
image are set to be ignored by the new process image. Signals set to
be caught by the calling process image are set to the default action
in the new process image (see <signal.h>).
And neither does it reset signal masks or flags.
In order to be transparent, when spawning new child processes to debug
(with "run", etc.), reset signal actions and mask back to what was
originally inherited from gdb/gdbserver's parent, just before execing
the target program to debug.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (SFILES): Add
common/signals-state-save-restore.c.
(HFILES_NO_SRCDIR): Add common/signals-state-save-restore.h.
(COMMON_OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* configure: Regenerate.
* fork-child.c: Include "signals-state-save-restore.h".
(fork_inferior): Call restore_original_signals_state.
* main.c: Include "signals-state-save-restore.h".
(captured_main): Call save_original_signals_state.
* common/common.m4: Add sigaction to AC_CHECK_FUNCS checks.
* common/signals-state-save-restore.c: New file.
* common/signals-state-save-restore.h: New file.
gdb/gdbserver/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* Makefile.in (OBS): Add signals-state-save-restore.o.
(signals-state-save-restore.o): New rule.
* config.in: Regenerate.
* configure: Regenerate.
* linux-low.c: Include "signals-state-save-restore.h".
(linux_create_inferior): Call
restore_original_signals_state.
* server.c: Include "dispositions-save-restore.h".
(captured_main): Call save_original_signals_state.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
PR gdb/18653
* gdb.base/signals-state-child.c: New file.
* gdb.base/signals-state-child.exp: New file.
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add new pattern.
With something like:
struct A { int bitfield:4; } var;
If 'var' ends up wholly-optimized out, printing 'var.bitfield' crashes
gdb here:
(top-gdb) bt
#0 0x000000000058b89f in extract_unsigned_integer (addr=0x2 <error: Cannot access memory at address 0x2>, len=2, byte_order=BFD_ENDIAN_LITTLE)
at /home/pedro/gdb/mygit/src/gdb/findvar.c:109
#1 0x00000000005a187a in unpack_bits_as_long (field_type=0x16cff70, valaddr=0x0, bitpos=16, bitsize=12) at /home/pedro/gdb/mygit/src/gdb/value.c:3347
#2 0x00000000005a1b9d in unpack_value_bitfield (dest_val=0x1b5d9d0, bitpos=16, bitsize=12, valaddr=0x0, embedded_offset=0, val=0x1b5d8d0)
at /home/pedro/gdb/mygit/src/gdb/value.c:3441
#3 0x00000000005a2a5f in value_fetch_lazy (val=0x1b5d9d0) at /home/pedro/gdb/mygit/src/gdb/value.c:3958
#4 0x00000000005a10a7 in value_primitive_field (arg1=0x1b5d8d0, offset=0, fieldno=0, arg_type=0x16d04c0) at /home/pedro/gdb/mygit/src/gdb/value.c:3161
#5 0x00000000005b01e5 in do_search_struct_field (name=0x1727c60 "bitfield", arg1=0x1b5d8d0, offset=0, type=0x16d04c0, looking_for_baseclass=0, result_ptr=0x7fffffffcaf8,
[...]
unpack_value_bitfield is already optimized-out/unavailable -aware:
(...) VALADDR points to the contents of VAL. If the VAL's contents
required to extract the bitfield from are unavailable/optimized
out, DEST_VAL is correspondingly marked unavailable/optimized out.
however, it is not considering the case of the value having no
contents buffer at all, as can happen through
allocate_optimized_out_value.
gdb/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* value.c (unpack_value_bitfield): Skip unpacking if the parent
has no contents buffer to begin with.
gdb/testsuite/ChangeLog:
2016-08-09 Pedro Alves <palves@redhat.com>
* gdb.dwarf2/bitfield-parent-optimized-out.exp: New file.
PR python/18565 notes that calling frame filters don't work properly for
inlined functions. This happens because Frame.function on an inline
frame will yield the wrong result. This patch changes this code to use
find_frame_funname instead, which handles inline frames properly.
Built and regtested on x86-64 Fedora 24.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* python/py-frame.c (frapy_function): Use find_frame_funname.
2016-08-03 Tom Tromey <tom@tromey.com>
PR python/18565:
* gdb.python/py-frame-inline.exp: Add Frame.function test.
"single-process" and "multi-process" are used in the test message of
process-dies-while-detaching.exp, but they are misplaced due to
set mode [expr {$multi_process ? "single-process" : "multi-process"}]
This patch is to swap them.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.threads/process-dies-while-detaching.exp (do_test): Set
variable mode to "multi-process" if $multi_process is 1, otherwise
set it to "single-process".
There are some gdb.cp/ tests fails if the program is compiled for arm
32-bit but GDB/GDBserver is aarch64 64-bit program, because target triplet
doesn't match "arm*-*-*". Instead, we can use is_aarch32_target.
gdb/testsuite:
2016-08-01 Yao Qi <yao.qi@linaro.org>
* gdb.cp/anon-struct.exp: Check is_aarch32_target.
* gdb.cp/cpexprs.exp: Likewise.
* gdb.cp/m-static.exp: Likewise.
PR python/20190 arose from an exception I noticed when trying to use
the Python unwinder for Spider Monkey in Firefox.
The problem is that the unwinder wants to examine the value of a
thread-local variable. However, sympy_value rejects this because
symbol_read_needs_frame returns true for a TLS variable.
This problem arose once before, though in a different context:
https://sourceware.org/bugzilla/show_bug.cgi?id=11803
At the time Pedro and Daniel pointed out a simpler way to fix that bug
(see links in 20190 if you are interested); but for this new bug I
couldn't think of a similar fix and ended up implementing Daniel's
other suggestion:
https://sourceware.org/ml/gdb-patches/2010-07/msg00393.html
That is, this patch makes it possible to detect whether a symbol needs
a specific frame, or whether it just needs the inferior to have
registers.
Built and regtested on x86-64 Fedora 24.
2016-07-26 Tom Tromey <tom@tromey.com>
* symtab.c (register_symbol_computed_impl): Update.
PR python/20190:
* value.h (symbol_read_needs): Declare.
(symbol_read_needs_frame): Add comment.
* symtab.h (struct symbol_computed_ops) <read_variable>: Update
comment.
<get_symbol_read_needs>: Rename. Change return type.
* findvar.c (symbol_read_needs): New function.
(symbol_read_needs_frame): Rewrite.
(default_read_var_value): Use symbol_read_needs.
* dwarf2loc.c (struct symbol_needs_baton): Rename.
<needs>: Renamed from needs_frame. Changed type.
(needs_frame_read_addr_from_reg, symbol_needs_get_reg_value)
(symbol_needs_read_mem, symbol_needs_frame_base)
(symbol_needs_frame_cfa, symbol_needs_tls_address)
(symbol_needs_dwarf_call): Rename.
(needs_dwarf_reg_entry_value): Update.
(symbol_needs_ctx_funcs, dwarf2_loc_desc_get_symbol_read_needs):
Rename and update.
(locexpr_get_symbol_read_needs, loclist_symbol_needs): Likewise.
(dwarf2_locexpr_funcs, dwarf2_loclist_funcs): Update.
* defs.h (enum symbol_needs_kind): New.
2016-07-26 Tom Tromey <tom@tromey.com>
PR python/20190:
* gdb.threads/tls.exp (check_thread_local): Add python symbol
test.
Some btrace tests use assembly source files. They use the target triplet to
distinguish between x86_64 and ia32 ISA. This does not work for -m32 tests
without setting the target triplet to i686-?-?.
Instead use is_amd64_regs_target to distinguish between x86_64 and ia32 ISA.
See also https://sourceware.org/ml/gdb-patches/2016-07/msg00256.html.
testsuite/
* gdb.btrace/record_goto.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/stepi.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall.exp: Use is_amd64_regs_target for selecting
assembly source files.
* gdb.btrace/tailcall-only.exp: Use is_amd64_regs_target for selecting
assembly source files.
When a bad interpreter name is passed to new-ui, such as:
(gdb) new-ui bloop /dev/pts/10
A partially created UI is left in the UI list, with interp set to NULL.
Trying to do anything that will print on this UI (such as "start") will
cause a segmentation fault.
Changes in v2:
- Use with_test_prefix to namespace test procedures
- Give an explicit stable test name
- Add a "bad terminal path" test
- Remove useless runto_main
- Add missing intro comments
I did not factor out the pty spawn, as there is some magic involved I
don't quite understand. But it wouldn't bring that much anyway.
gdb/ChangeLog:
* top.h (make_delete_ui_cleanup): New declaration.
* top.c (delete_ui_cleanup): New function.
(make_delete_ui_cleanup): New function.
(new_ui_command): Create restore_ui cleanup earlier, create a
delete_ui cleanup and discard it on success.
gdb/testsuite/ChangeLog:
* gdb.base/new-ui.exp (do_test_invalid_args): New
procedure.
This patch allows gdbserver to continue recording after disconnect. On
reconnect, the recorded data is accessible to gdb as if no disconnect happened.
A possible application for this feature is remotely examine bugs that occur
at irregular intervals, where maintaining a gdb connection is inconvenient.
This also fixes the issue mentioned here:
https://sourceware.org/ml/gdb-patches/2015-11/msg00424.html
Signed-off-by: Tim Wiederhake <tim.wiederhake@intel.com>
gdb/ChangeLog:
* NEWS: Resume btrace on reconnect.
* record-btrace.c: Added record-btrace.h include.
(record_btrace_open): Split into this and ...
(record_btrace_push_target): ... this.
(record_btrace_disconnect): New function.
(init_record_btrace_ops): Use record_btrace_disconnect.
* record-btrace.h: New file.
* remote.c: Added record-btrace.h include.
(remote_start_remote): Check recording status.
(remote_btrace_maybe_reopen): New function.
gdb/doc/ChangeLog:
* gdb.texinfo: Resume btrace on reconnect.
gdb/testsuite/ChangeLog:
* gdb.btrace/reconnect.c: New file.
* gdb.btrace/reconnect.exp: New file.
Change-Id: I95e8b0ab8a89e58591aba0e63818cee82fd211bc
Implement support to add catchpoints for a group of related syscalls
using the syntax:
(gdb) catch syscall group:<group>
or
(gdb) catch syscall g:<group>
Several groups are predefined in the xml files for all architectures
supported by GDB over Linux. They are based on the groups defined by
strace.
gdb/
* xml-syscall.c (get_syscalls_by_group): New.
(get_syscall_group_names): New.
(struct syscall_group_desc): New structure to store group data.
(struct syscalls_info): Include field to store the group list.
(sysinfo_free_syscall_group_desc): New.
(free_syscalls_info): Free group list.
(syscall_group_create_syscall_group_desc): New.
(syscall_group_add_syscall): New.
(syscall_create_syscall_desc): Add syscall to its groups.
(syscall_start_syscall): Load group attribute.
(syscall_group_get_group_by_name): New.
(xml_list_syscalls_by_group): New.
(xml_list_of_groups): New.
* xml-syscall.h (get_syscalls_by_group): Export function
to retrieve a list of syscalls filtered by the group name.
(get_syscall_group_names): Export function to retrieve the list
of syscall groups.
* break-catch-syscall.c (catch_syscall_split_args): Verify if
argument is a syscall group and expand it to a list of syscalls
when creating catchpoints.
(catch_syscall_completer): Add word completion for system call
groups.
* configure.ac: Include dependency for xsltproc when building
in maintainer-mode.
* break-catch-syscall.c (_initialize_breakpoint): Update catch
syscall command documentation.
* NEWS: Include section about catching groups of syscalls.
* configure: Regenerate.
* data-directory/Makefile.in: Generate syscall xml when building
in maintainer mode.
* syscalls/gdb-syscalls.dtd: Include group attribute to the
syscall element.
* syscalls/apply-defaults.xsl: New.
* syscalls/linux-defaults.xml.in: New.
* syscalls/aarch64-linux.xml: Rename to aarch64-linux.xml.in.
* syscalls/amd64-linux.xml: Rename to amd64-linux.xml.in.
* syscalls/arm-linux.xml: Rename to arm-linux.xml.in.
* syscalls/bfin-linux.xml: Rename to bfin-linux.xml.in.
* syscalls/i386-linux.xml: Rename to i386-linux.xml.in.
* syscalls/mips-n32-linux.xml: Rename to mips-n32-linux.xml.in.
* syscalls/mips-n64-linux.xml: Rename to mips-n64-linux.xml.in.
* syscalls/mips-o32-linux.xml: Rename to mips-o32-linux.xml.in.
* syscalls/ppc-linux.xml: Rename to ppc-linux.xml.in.
* syscalls/ppc64-linux.xml: Rename to ppc64-linux.xml.in.
* syscalls/s390-linux.xml: Rename to s390-linux.xml.in.
* syscalls/s390x-linux.xml: Rename to s390x-linux.xml.in.
* syscalls/sparc-linux.xml: Rename to sparc-linux.xml.in.
* syscalls/sparc64-linux.xml: Rename to sparc64-linux.xml.in.
* syscalls/aarch64-linux.xml: Regenerate.
* syscalls/amd64-linux.xml: Regenerate.
* syscalls/arm-linux.xml: Regenerate.
* syscalls/i386-linux.xml: Regenerate.
* syscalls/mips-n32-linux.xml: Regenerate.
* syscalls/mips-n64-linux.xml: Regenerate.
* syscalls/mips-o32-linux.xml: Regenerate.
* syscalls/ppc-linux.xml: Regenerate.
* syscalls/ppc64-linux.xml: Regenerate.
* syscalls/s390-linux.xml: Regenerate.
* syscalls/s390x-linux.xml: Regenerate.
* syscalls/sparc-linux.xml: Regenerate.
* syscalls/sparc64-linux.xml: Regenerate.
gdb/testsuite/
* gdb.base/catch-syscall.exp (do_syscall_tests): Add call
to test_catch_syscall_group.
(test_catch_syscall_group): New.
gdb/doc/
* gdb.texinfo (Set Catchpoints): Add 'group' argument to catch
syscall.
I learned recently that empty struct expressions, like "X{}", have been
promoted from experimental to stable in Rust. This patch changes the
Rust expression parser to allow this case.
New test case included.
Built and regtested on x86-64 Fedora 23, using Rust 1.11 beta.
2016-07-21 Tom Tromey <tom@tromey.com>
* rust-lang.c (rust_tuple_struct_type_p): Return false for empty
structs.
* rust-exp.y (struct_expr_list): Allow empty elements.
2016-07-21 Tom Tromey <tom@tromey.com>
* gdb.rust/simple.rs (main): Use empty struct expression.
* gdb.rust/simple.exp: Add tests for empty struct expression.
I recently see some gdb.server/*.exp fails in my native gdb testing,
in which libexpat isn't available, so GDB isn't able to parse xml file.
It causes gdb.server/ tests fails because GDB can't get registers
correctly from GDBserver.
(gdb) PASS: gdb.server/connect-without-multi-process.exp: multiprocess=off: break main
target remote localhost:2352^M
Remote debugging using localhost:2352^M
warning: Can not parse XML target description; XML support was disabled at compile time^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.^M
Reading /lib/ld-linux-armhf.so.3 from remote target...^M
Reading symbols from target:/lib/ld-linux-armhf.so.3...Reading /lib/ld-2.17.so.debug from remote target...^M
Reading /lib/.debug/ld-2.17.so.debug from remote target...^M
(no debugging symbols found)...done.^M
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000efffbe00000000808d0f4d100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000^
0x4d0f8d80 in _start () from target:/lib/ld-linux-armhf.so.3^M
Without XML support in GDB, it can't parse xml sent by GDBserver, and has
to fall back to the oldest arch. However, GDBserver doesn't know this
(IMO, this is a defect in RSP), and still choose the right target
description to create regcache and 'g' packet. If the port only has
one target description or coincidentally two sides choose the same
target description, there is no such issue. Otherwise, GDB is broken
on read registers.
This patch is to skip gdbserver tests if XML is not support and the
target has multiple target descriptions.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* lib/gdbserver-support.exp (skip_gdbserver_tests): Return 1
if gdb_skip_xml_test is true on some targets.
If I run single test solib-list.exp, it is OK. If I run two, as below,
there are fails,
$ make check RUNTESTFLAGS="server-run.exp solib-list.exp"
FAIL: gdb.server/solib-list.exp: non-stop 0: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 0: p libvar
FAIL: gdb.server/solib-list.exp: non-stop 1: continue (the program exited)
FAIL: gdb.server/solib-list.exp: non-stop 1: p libvar
in gdb.log,
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/server-run/server-run /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
server-run is spawned, which is wrong. If I only run solib-list.exp, ld-linux
is spawned, which is right.
/scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../../gdb/gdbserver/gdbserver --once :2346 /lib64/ld-linux-x86-64.so.2 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/outputs/gdb.server/solib-list/solib-list
in test, we spawn gdbserver this way,
# Note we pass ${interp_system}, the program gdbserver spawns, as
# argument here, instead of using gdb_load, because we don't want
# to download the interpreter to the target (it's already there)
# or to the test output directory.
set res [gdbserver_spawn "${interp_system} ${remote_binfile}"]
in gdbserver_spawn -> gdbserver_download_current_prog, if
last_loaded_file is set (when you run multiple tests), it is
returned.
This patch is to unset last_loaded_file in solib-list.exp.
gdb/testsuite:
2016-07-21 Yao Qi <yao.qi@linaro.org>
* gdb.server/solib-list.exp: Unset last_loaded_file.
tested on Fedora 24 x86_64 after:
./configure; make
That is: CFLAGS='-g -O2' CXXFLAGS='-g -O2'
FAIL: gdb.gdb/selftest.exp: unknown source line
FAIL: gdb.gdb/selftest.exp: step into xmalloc call
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.gdb/selftest.exp (do_steps_and_nexts): Add "next over TRY" and
"step into captured_main (args)".
$ runtest 'CC_FOR_TARGET=gcc -m32' gdb.btrace/tailcall-only.exp
Running ./gdb.btrace/tailcall-only.exp ...
gdb compile failed, tailcall-only.c: Assembler messages:
tailcall-only.c:142: Error: cannot represent relocation type BFD_RELOC_64
[...]
tailcall-only.c:425: Error: cannot represent relocation type BFD_RELOC_64
It works for the other x86 arch combinations:
On Mon, 11 Apr 2016 08:44:23 +0200, Metzger, Markus T wrote:
I'm setting the target triplet to "i686-unknown-linux" in my m32 configuration.
Like this:
set target_triplet "i686-unknown-linux"
set_board_info cflags "-m32"
set_board_info cppflags "-m32"
On Wed, 20 Jul 2016 16:02:20 +0200, Pedro Alves wrote:
There's no reason you should _not_ set it.
But, multilib-style testing with --target_board=unix\{-m64,-m32\} etc.
should work _too_, IMO.
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.btrace/tailcall-only.exp: Use is_lp64_target check.
(gdb) source /home/jkratoch/redhat/gdb-clean/gdb/testsuite/outputs/gdb.python/py-unwind/py-unwind.py^M
Python script imported^M
Python Exception <type 'exceptions.ValueError'> Bad register: ^M
(gdb) FAIL: gdb.python/py-unwind.exp: import python scripts
class TestUnwinder(Unwinder):
AMD64_RBP = 6
AMD64_RSP = 7
AMD64_RIP = 16
On Tue, 19 Jul 2016 12:06:09 +0200, Yao Qi wrote:
py-unwind.exp does nothing on arch specific thing, so py-unwind.exp shouldn't
be aware of the arch difference, but py-unwind.py should.
On Tue, 19 Jul 2016 20:04:33 +0200, Pedro Alves wrote:
How about we handle this in the .exp file for now and leave something
more complicated for when the test is first ported to some other
arch. WDYT?
gdb/testsuite/ChangeLog
2016-07-20 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.python/py-unwind.exp: Test also ![is_lp64_target].
A test recently added to gdb.opt/inline-cmds.exp fails for
arm-none-eabi targets because -O2 leads to instructions to be
reordered widely.
I guess it might have made sense years ago to enable optimization in
these tests, but I fail to see the need for that nowadays.
Using -O0 while relying on __attribute__((always_inline)), which is
already used in the tests [1] [2], avoids this sort of trouble, while
still exercising the inlining-related use cases that are the focus of
these tests.
I think that nowadays we can safely assume that all compilers we care
about support __attribute__((always_inline)) or similar.
[1] - Except one spot that missed it.
[2] - Note that the .exp files make sure the frames that should have
been inlined are indeed inlined, with "info frame".
gdb/testsuite/ChangeLog:
2016-07-19 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-break.exp: Remove optimize=-O2.
* gdb.opt/inline-bt.exp: Likewise.
* gdb.opt/inline-cmds.exp: Remove optimize=-O2 and add
additional_flags=-Winline.
* gdb.opt/inline-locals.exp: Likewise.
* gdb.opt/inline-markers.c (ATTR): Define.
(inlined_fn): Use it.
This patch uses do_self_tests to simplify selftest.exp. It doesn't
change the tests except the order,
-PASS: gdb.gdb/selftest.exp: Disassemble main
PASS: gdb.gdb/selftest.exp: breakpoint in captured_main
+PASS: gdb.gdb/selftest.exp: run until breakpoint at captured_main
+PASS: gdb.gdb/selftest.exp: Disassemble main
PASS: gdb.gdb/selftest.exp: set interrupt character in test_with_self
PASS: gdb.gdb/selftest.exp: set listsize to 1
-PASS: gdb.gdb/selftest.exp: run until breakpoint at captured_main
gdb/testsuite:
2016-07-19 Yao Qi <yao.qi@linaro.org>
* gdb.gdb/selftest.exp: Remove checks on is_remote and isnative.
(test_with_self): Remove some code. Remove argument executable.
(top-level): Use do_self_tests.
This patch fixes problems with a few GDB testsuites when executing in a
path that contains special characters (e.g. "++"). When such paths are
used as a regular expression, the regular expression parser will choke
and cause the tests to fail. This patch uses string_to_regexp to
escape strings that will be used as regular expressions, in order to
sanitize path names used in expect scripts.
2016-07-15 Zachary Welch <zwelch@codesourcery.com>
Don Breazeal <donb@codesourcery.com>
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: Escape paths used in regular expressions.
* gdb.stabs/weird.exp: Likewise.
This patch adds some breakpoint events to Python. In particular,
there is a creation event that is emitted when a breakpoint is
created; a modification event that is emitted when a breakpoint
changes somehow; and a deletion event that is emitted when a
breakpoint is deleted.
In this patch, the event's payload is the breakpoint itself. I
considered making a new event type to hold the breakpoint, but I
didn't see a need. Still, I thought I would mention this as a spot
where some other choice is possible.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python/py-evts.c (gdbpy_initialize_py_events): Call
add_new_registry for new events.
* python/py-events.h (events_object) <breakpoint_created,
breakpoint_deleted, breakpoint_modified>: New fields.
* python/py-breakpoint.c (gdbpy_breakpoint_created): Emit the
breakpoint changed event.
(gdbpy_breakpoint_deleted): Emit the breakpoint deleted event.
(gdbpy_breakpoint_modified): New function.
(gdbpy_initialize_breakpoints): Attach to the breakpoint modified
observer.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* python.texi (Events In Python): Document new breakpoint events.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/15620, PR python/18620:
* gdb.python/py-breakpoint.exp (connect_event, check_last_event)
(test_bkpt_events): New procs.
This patch adds a "pending" attribute to gdb.Breakpoint.
Built and regtested on x86-64 Fedora 23.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* NEWS: Update.
* python/py-breakpoint.c (bppy_get_pending): New function.
(breakpoint_object_getset): Add entry for "pending".
* breakpoint.h (pending_breakpoint_p): Declare.
* breakpoint.c (pending_breakpoint_p): New function.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* python.texi (Breakpoints In Python): Document
Breakpoint.pending.
2016-07-13 Tom Tromey <tom@tromey.com>
PR python/17698:
* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add "pending"
test.
(test_watchpoints): Likewise.
(test_bkpt_pending): New proc.
PR cli/18053 concerns a couple of minor bugs in the JIT debuginfo
support. First, jit-reader-load should use filename completion and
support tilde expansion. Second, the help for jit-reader-unload is
incorrect. While working on this I also realized that
jit-reader-unload should use the no-op completer, so I've included
that as well.
Built and regtested on x86-64 Fedora 23. A completer test for
jit-reader-load is included, but not a tilde-expansion test, as I
couldn't think of a reliable way to test that.
2016-07-13 Tom Tromey <tom@tromey.com>
PR cli/18053:
* jit.c (jit_reader_load_command): Use tilde_expand.
(_initialize_jit): Fix help for jit-reader-unload. Set completer
for new commands.
2016-07-13 Tom Tromey <tom@tromey.com>
PR cli/18053:
* gdb.base/jit-so.exp (one_jit_test): Add jit-reader-load
completion test.
Marin Cermak has found various testcases (or one of them) of GDB FAIL on
ppc64.
https://sourceware.org/bugzilla/show_bug.cgi?id=20328
.o contained only the function descriptor address.
The DWARF as produced by Tcl Dwarf::assemble:
<1><27>: Abbrev Number: 4 (DW_TAG_subprogram)
<28> DW_AT_name : main
<2d> DW_AT_external : 1
<2e> DW_AT_low_pc : 0x1001ff98
<36> DW_AT_high_pc : 0x1002ff98
<2><3e>: Abbrev Number: 5 (DW_TAG_lexical_block)
Runtime info:
$2 = {<text variable, no debug info>} 0x10000674 <.main>
$3 = {void ()} 0x1001ff98 <main>
On Tue, 12 Jul 2016 15:22:49 +0200, Ulrich Weigand wrote:
Well, most of the gdb.dwarf2 test cases simply use explicitly placed labels
for the DW_AT_low_pc / DW_AT_high_pc attributes.
See e.g. dw2-unresolved-main.c:
asm (".globl cu_text_start");
asm ("cu_text_start:");
On Wed, 13 Jul 2016 10:54:00 +0200, Jan Kratochvil wrote:
Now I see I should not do that because:
lib/dwarf.exp:
proc function_range { func src } {
So I am providing this patch.
gdb/testsuite/ChangeLog
2016-07-13 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.dwarf2/atomic-type.exp: Use function_range for low_pc and high_pc.
* gdb.dwarf2/atomic.c (f): Rename f_end_lbl to f_label.
* gdb.dwarf2/dw2-bad-mips-linkage-name.c (f): Rename f_end_lbl to
f_label.
(g): Rename g_end_lbl to g_label.
* gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Use function_range for
low_pc and high_pc.
* gdb.dwarf2/dw2-lexical-block-bare.exp: Likewise.
PR python/19293 notes that when a Python unwinder is disabled, the
frame cache is not invalidated. This means that disabling an unwinder
doesn't have any immediate effect -- but in my experience it's often
the case that I want to enable or disable an unwinder in order to see
what happens.
This patch adds a new gdb.invalidate_cached_frames function and
arranges for the relevant bits of library code to call it. I've only
partially documented this function, considering a warning sufficient
without going into all the reasons ordinary code should not call it.
The name of the new function was taken from a comment in frame.h next
to reinit_frame_cache.
No new test as I think the updates to the existing test are sufficient
to show that the code is working as intended.
Built and regtested on x86-64 Fedora 23.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* python/lib/gdb/command/unwinders.py (do_enable_unwinder): Call
gdb.invalidate_cached_frames.
* python/lib/gdb/unwinder.py (register_unwinder): Call
gdb.invalidate_cached_frames.
* python/python.c (gdbpy_invalidate_cached_frames): New function.
(python_GdbMethods): Add entry for invalidate_cached_frames.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* python.texi (Frames In Python): Document
gdb.invalidate_cached_frames.
2016-07-12 Tom Tromey <tom@tromey.com>
PR python/19293:
* gdb.python/py-unwind-maint.exp: Update tests.
In gdb.gdb/observer.exp, I see the following fail,
(gdb) break captured_main^M
Breakpoint 1 at 0x57e409: file ../../binutils-gdb/gdb/main.c, line 492.^M
(gdb) PASS: gdb.gdb/observer.exp: breakpoint in captured_main
run -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
Starting program: /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/outputs/gdb.gdb/observer/xgdb -nw -nx -data-directory /home/yao.qi/SourceCode/gnu/build/gdb/testsuite/../data-directory^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".^M
^M
Breakpoint 1, gdb_main (args=args@entry=0x7fffffffdca0) at ../../binutils-gdb/gdb/main.c:1157^M
1157 captured_main (args);^M
(gdb) FAIL: gdb.gdb/observer.exp: run until breakpoint at captured_main
looks the test sets breakpoint on captured_main, and expects program
stops at captured_main. However, program stops at the place where
captured_main is called, because captured_main is inlined,
<1><8519e3>: Abbrev Number: 58 (DW_TAG_subprogram)
<8519e4> DW_AT_name : (indirect string, offset: 0x880d3): captured_main
<8519e8> DW_AT_decl_file : 1
<8519e9> DW_AT_decl_line : 444
<8519eb> DW_AT_type : <0x846e48>
<8519ef> DW_AT_inline : 1 (inlined)
<8519f0> DW_AT_sibling : <0x851c01>
The test passes if I build GDB with '-O0 -g3', because captured_main
isn't inlined. This patch is to match the output when captured_main
is inlined.
gdb/testsuite:
2016-07-12 Yao Qi <yao.qi@linaro.org>
* lib/selftest-support.exp (selftest_setup): Match the output
when captured_main is inlined.
Using the default lookup for the symbol "this" might lead to segmentation
fault in GDB.
Some languages, e.g. Fortran, use as default lookup routine the C++
routines.
For those languages "this" can be the instance of a class or even the
definition of a class.
When an instance of a class having the name "this" is evaluated
in GDB a segmentation fault was observed.
As example of the issue take into consideration the Fortran code:
type foo
real :: a
type(bar) :: x
character*7 :: b
end type foo
type(foo) :: this
Issue appears when evaluating the variable "this" in GDB.
Within the language definition structure there is a field that represents
the name of the special symbol used for the C++ "this" for the language
being described.
The fix presented here takes into account the aforementioned field. In the
case the aforementioned field is NULL "this" is not represented in the
language described and the lookup should return a null_block_symbol.
Tests: Performed tests with gfortran and ifort.
Reviewed:
https://sourceware.org/ml/gdb-patches/2016-04/msg00068.html
After the commited patch:
https://sourceware.org/ml/gdb-patches/2016-06/msg00364.html
Patch can be applied.
2016-06-16 Walfred Tedeschi <walfred.tedeschi@intel.com>
gdb/ChangeLog:
* cp-namespace.c (cp_lookup_bare_symbol): Use language passed as
parameter to look for the symbol "this".
gdb/testsuite/ChangeLog:
* gdb.fortran/derived-types.exp (result_line, result_line_2):
New variables.
(print this%a, print this%b, print this): New tests.
* gdb.fortran/derived-types.f90 (this): New object and
initialization.
The output of Ada tests create a layout where the test name
("formatted_ref" in this example) appears twice:
outputs
└── gdb.ada
└── formatted_ref
└── formatted_ref
├── b~formatted_ref.adb
├── b~formatted_ref.ads
├── b~formatted_ref.ali
├── b~formatted_ref.o
├── defs.ali
├── defs.o
├── formatted_ref
├── formatted_ref.ali
└── formatted_ref.o
This causes a problem when testing with the native-gdbserver board, when
the binary has the same name as the test. When gdb_remote_download is
called to upload the compiled binary, the implementation for
native-gdbserver copies it in the standard output directory (in
outputs/gdb.ada/formatted_ref). However, there is already a directory
named formatted_ref in there, so the copy fails and gdbserver isn't able
to load the binary.
This patch bypasses the problem by removing the extra directory level.
The compiled binary will already be in its final location in the
standard output directory, so the copy will effectively be a no-op.
gdb/testsuite/ChangeLog:
* lib/ada.exp: Remove extra directory level in build directory.
* gdb.ada/cond_lang.exp: Likewise.
* gdb.ada/exec_changed.exp: Likewise.
* gdb.ada/lang_switch.exp: Likewise.
This will be useful for dealing with vectors; regardless of our final solution
for the Index trait.
2016-07-06 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_subscript): Allow subscripting pointers
gdb/testsuite/ChangeLog:
* simple.rs: Add test for raw pointer subscripting
* simple.exp: Add test expectations
Commit 38b022b445 adds "method" and
"format" fields in =record-started, but doesn't update test case
gdb.mi/mi-reverse.exp, so it causes the fail like this,
PASS: gdb.mi/mi-reverse.exp: mi runto main
Expecting: ^(-interpreter-exec console record[^M
]+)?(=record-started,thread-group="i1"^M
\^done[^M
]+[(]gdb[)] ^M
[ ]*)
-interpreter-exec console record^M
=record-started,thread-group="i1",method="full"^M
^done^M
(gdb) ^M
FAIL: gdb.mi/mi-reverse.exp: Turn on process record
and regression was found by buildbot too
https://sourceware.org/ml/gdb-testers/2016-q2/msg04492.html
gdb/testsuite:
2016-07-05 Yao Qi <yao.qi@linaro.org>
* gdb.mi/mi-reverse.exp: Match =record-started output.
The jit-reader.exp test isn't really exercising the jit-reader's
unwinder API at all. This commit address that, and then fixes GDB
problems exposed.
- The custom JIT reader provided for the jit-reader.exp testcase
always rejects the jitted function's frame...
This is because the custom JIT reader in the testcase never ever
sets state->code_begin/end, so the bounds check in
gdb.base/jitreader.c:unwind_frame:
if (this_ip >= state->code_end || this_ip < state->code_begin)
return GDB_FAIL;
tends to fail, unless you're "lucky" (because it references
uninitialized data).
The result is that GDB is always actually using a built-in unwinder
for the jitted function.
- The provided unwinder doesn't do anything that GDB's built-in
unwinder can't do.
IOW, we can't really tell whether the JIT reader's unwinder is
working or not.
I fixed that by making the jitted function mangle its own stack
pointer with a xor, and then teaching the jit unwinder to demangle
it back (another xor). So now "backtrace" with GDB's built-in
unwinder fails while with the jit unwinder, it succeeds.
- GDB crashes after unloading the JIT reader, and flushing frames...
I made the testcase use the "flushregs" command after unloading the
JIT reader, to force the JIT frames to be flushed. However, that
crashes GDB...
When reinit_frame_cache tears down a frame's cache, it calls its
unwinder's dealloc_cache method, which for JIT frames ends up in
jit.c:jit_dealloc_cache. This function calls each of the frame's
gdb_reg_value's "free" pointer:
for (i = 0; i < gdbarch_num_regs (frame_arch); i++)
if (priv_data->registers[i] && priv_data->registers[i]->free)
priv_data->registers[i]->free (priv_data->registers[i]);
and the problem is these gdb_reg_value instances have been returned
by the JIT reader that has been already unloaded, and their "free"
function pointers likely point to functions in the DSO that has
already been unloaded...
A fix for that could be to call reinit_frame_cache in
jit_reader_unload_command _before_ unloading the jit reader DSO so
that the jit reader is given a chance to clean up the gdb_reg_values
before it is unloaded. However, the fix for the point below makes
this unnecessary, because it stops jit.c from keeping around
gdb_reg_values in the first place.
- However, it still makes sense to clear the frame cache when loading
or unloading a JIT unwinder.
This makes testing a JIT unwinder a bit simpler.
- Not only the frame cache actually -- gdb is not unloading the
jit-registered objfiles when the JIT reader is unloaded, and not
loading the already-registered descriptors when a JIT reader is
loaded.
The new test exercises unloading the jit reader, loading it back
again, and then making sure the JIT reader's unwinder works again.
Without the unload/re-load of already-read descriptors, the newly
loaded JIT would have no idea where the new function is, because
it's stored at symbol read time.
- I added a couple "info frame" calls to the test, and that
crashes GDB...
The problem is that jit_frame_prev_register assumes it'll only be
called for raw registers, so when it gets a pseudo register number,
the "priv->registers[reg]" access is really an out-of-bounds access.
To fix that, I made jit_frame_prev_register use
gdbarch_pseudo_register_read_value for reading the pseudo-registers.
However, that works with a regcache and we don't have one. To fix
that, I made the JIT unwinder store a regcache in its cache instead
of an array of gdb_reg_value pointers.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Tom Tromey <tom@tromey.com>
* jit.c (jit_reader_load_command): Call reinit_frame_cache and
jit_inferior_created_hook.
(jit_reader_unload_command): Call reinit_frame_cache and
jit_inferior_exit_hook.
* jit.c (struct jit_unwind_private) <registers>: Delete field.
<regcache>: New field.
(jit_unwind_reg_set_impl): Set the register's value in the
regcache. Free the passed-in gdb_reg_value.
(jit_dealloc_cache): Adjust to free the regcache.
(jit_frame_sniffer): Allocate a regcache instead of an array of
gdb_reg_value pointers.
(jit_frame_this_id): Adjust.
(jit_frame_prev_register): Read raw registers off of the regcache
instead of from the gdb_reg_value pointer array. Use
gdbarch_pseudo_register_read_value to read pseudo registers.
* regcache.c (regcache_raw_set_cached_value): New function,
factored out from ...
(regcache_raw_write): ... here.
* regcache.h (regcache_raw_set_cached_value): Declare.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.base/jit-reader.exp (info_registers_current_frame): New
procedure.
(jit_reader_test): Test the jit reader's unwinder.
* gdb.base/jithost.c (jit_function_00_code): New global.
(main): Use memcpy to fill in the mmapped code, instead of poking
bytes manually here.
* gdb.base/jitreader.c (enum register_mapping) <AMD64_RBP>: New
value.
(read_debug_info): Save the function's range.
(read_sp): New function.
(unwind_frame): Use it. Also unwind RBP.
(get_frame_id): Use read_sp.
(gdb_init_reader): Use calloc instead of malloc.
* lib/gdb.exp (get_hexadecimal_valueof): Add optional 'test'
parameter. Use gdb_test_multiple.
This commit fixes detaching on Linux when some thread exits the whole
thread group (process) just while we're detaching.
On Linux, a ptracer must detach from each LWP individually, with
PTRACE_DETACH. Since PTRACE_DETACH sets the thread running free, if
one of the already-detached threads causes the whole thread group to
exit (e.g., simply calls exit), the kernel force-kills the other
threads in the group, making them zombie, just as we're still
detaching them. Since PTRACE_DETACH against a zombie thread fails
with ESRCH, and gdb/gdbserver are not expecting this, the detach fails
with an error like: "Can't detach process: No such process.".
This patch detects this detach failure as normal, and instead of
erroring out, reaps the now-dead thread.
New test included, that exercises several different scenarios that
cause GDB/GDBserver to error out when it should not.
Tested on x86-64 GNU/Linux with {unix, native-gdbserver,
native-extended-gdbserver}
Note: without the previous fix, the "single-process + continue"
variant of the new test would fail with:
(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: switch to parent
continue
Continuing.
Warning:
Could not insert hardware watchpoint 3.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint: continue
gdb/gdbserver/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* linux-low.c: Change interface to take the target lwp_info
pointer directly and return void. Handle detaching from a zombie
thread.
(linux_detach_lwp_callback): New function.
(linux_detach): Detach from the leader thread after detaching from
the clone threads.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* inf-ptrace.c (inf_ptrace_detach_success): New function, factored
out from ...
(inf_ptrace_detach): ... here.
* inf-ptrace.h (inf_ptrace_detach_success): New declaration.
* linux-nat.c (get_pending_status): Rename to ...
(get_detach_signal): ... this, and return a host signal instead of
filling in a wait status.
(detach_one_lwp): New function, factored out from detach_callback
and adjusted to handle detaching from a zombie thread.
(detach_callback): Skip the leader thread.
(linux_nat_detach): No longer defer to inf_ptrace_detach to detach
the leader thread, nor build a signal string to pass down.
Instead, use target_announce_detach, detach_one_lwp and
inf_ptrace_detach_success.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
Antoine Tremblay <antoine.tremblay@ericsson.com>
* gdb.threads/process-dies-while-detaching.c: New file.
* gdb.threads/process-dies-while-detaching.exp: New file.
If you have two inferiors (or more), set watchpoints in one of the
inferiors, and then that inferior exits, until you manually delete the
watchpoint (or something forces a breakpoint re-set), you can't resume
the other inferior.
This is exercised by the test added by this commit. Without the GDB
fix, this test fails like this:
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=detach: continue to marker in inferior 1
FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=exit: continue to marker in inferior 1
and gdb.log shows (in all three cases):
(gdb) continue
Continuing.
Warning:
Could not insert hardware watchpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
Command aborted.
(gdb) FAIL: gdb.multi/watchpoint-multi-exit.exp: dispose=kill: continue to marker in inferior 1
The problem is that GDB doesn't forget about the locations of
watchpoints set in the inferior that is now dead. When we try to
continue the inferior that is still alive, we reach
insert_breakpoint_locations, which has the the loop that triggers the
error:
/* If we failed to insert all locations of a watchpoint, remove
them, as half-inserted watchpoint is of limited use. */
That loop finds locations that are not marked inserted, but which
according to should_be_inserted should have been inserted, and so
errors out.
gdb/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* breakpoint.c (breakpoint_init_inferior): Discard watchpoint
locations.
* infcmd.c (detach_command): Call breakpoint_init_inferior.
gdb/testsuite/ChangeLog:
2016-07-01 Pedro Alves <palves@redhat.com>
* gdb.multi/watchpoint-multi-exit.c: New file.
* gdb.multi/watchpoint-multi-exit.exp: New file.
Commit 51f77c3704 ("Add testing infrastruture bits for running with
MI on a separate UI") broke MI testing with native-gdbserver:
$ make check RUNTESTFLAGS="--target_board=native-gdbserver mi-var-child.exp"
...
Running .../src/binutils-gdb/gdb/testsuite/gdb.mi/mi-var-child.exp ...
can't unset "inferior_spawn_id": no such variable
while executing
"unset inferior_spawn_id"
(procedure "close_gdbserver" line 20)
invoked from within
"close_gdbserver"
...
When testing with gdbserver, gdb_exit is overridden with a special
version that calls close_gdbserver, which clears inferior_spawn_id.
The problem is that the commit mentioned above made
gdb_exit/mi_gdb_exit clear inferior_spawn_id too, and clearing a
non-existing variable is a tcl error.
Since gdb_exit/mi_gdb_exit always clears inferior_spawn_id now, the
fix is simply to stop clearing it in close_gdbserver.
gdb/testsuite/
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/gdbserver-support.exp (close_gdbserver, gdb_exit): Don't
unset inferior_spawn_id.
Runing the whole gdb testsuite with MI on a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
Doesn't actually work because commit 51f77c3704 ("Add testing
infrastruture bits for running with MI on a separate UI") included a
last-minute rename typo, now fixed with this commit.
gdb/testsuite/ChangeLog:
2016-06-30 Pedro Alves <palves@redhat.com>
* lib/mi-support.exp (default_mi_gdb_start): Declare global
FORCE_SEPARATE_MI_TTY, not SEPARATE_MI_TTY.
PR python/20129 concerns the error message one gets from a command
like "disable frame-filter global NoSuchFilter". Currently this
throws a second, unexpected, exception due to the use of a
non-existing variable named "name".
This patch adds regression tests and fixes a couple of spots to use
the correct variable name.
Built and regtested on x86-64 Fedora 23.
2016-06-29 Tom Tromey <tom@tromey.com>
PR python/20129:
* python/lib/gdb/command/frame_filters.py (_do_enable_frame_filter)
(SetFrameFilterPriority._set_filter_priority): Use "frame_filter",
not "name".
2016-06-29 Tom Tromey <tom@tromey.com>
PR python/20129:
* gdb.python/py-framefilter.exp: Add tests for setting priority
and disabling of non-existent frame filter.
Currently, we use 123456789 as unknown or illegal syscall number, and
expect program return ENOSYS. Although 123456789 is an illegal syscall
number on arm linux, kernel sends SIGILL rather than returns -ENOSYS.
However, arm linux kernel returns -ENOSYS if syscall number is within
0xf0001..0xf07ff, so we can use 0xf07ff for unknown_syscall in test.
gdb/testsuite:
2016-06-29 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.c [__arm__]: Set unknown_syscall to
0x0f07ff.
In 82075af2c1 (Implement 'catch syscall'
for gdbserver), only x86 is supported, but the test can still be run
on other linux targets, like aarch64 and ppc, with native-gdbserver.
This causes many new fails.
This patch removes the check on isnative and on target triplets.
Instead, we can insert catch point, and resume the program to see whether
catch syscall is supported or not.
gdb/testsuite:
2016-06-28 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp: Remove check on isnative and target
triplets. Start gdb, execute catch syscall, and continue. Check
gdb's output to determine catch syscall is supported.
Rust prefers to not specify the return type of a function when it is unit
(`()`). The type is also referred to as "void" in debuginfo but not in actual
usage, so we should never be printing "void" when the language is Rust.
2016-06-27 Manish Goregaokar <manish@mozilla.com>
gdb/ChangeLog:
* rust-lang.c (rust_print_type): Print unit types as "()"
* rust-lang.c (rust_print_type): Omit return type for functions
returning unit
gdb/testsuite/ChangeLog:
* gdb.rust/simple.rs: Add test for returning unit in a function
* gdb.rust/simple.exp: Add expectation for functions returning unit
When a Python script tries to create a breakpoint but fails to do so,
gdb.Breakpoint.__init__ raises an exception and the breakpoint does not
exist anymore in the Python interpreter. However, GDB still keeps a
reference to the Python object to be used for a later hook, which is
wrong.
This commit adds the necessary cleanup code so that there is no stale
reference to this Python object. It also adds a new testcase to
reproduce the bug and check the fix.
2016-06-25 Pierre-Marie de Rodat <derodat@adacore.com>
gdb/
* python/py-breakpoint.c (bppy_init): Clear bppy_pending_object
when there is an error during the breakpoint creation.
gdb/testsuite
* gdb.python/py-breakpoint-create-fail.c,
gdb.python/py-breakpoint-create-fail.exp,
gdb.python/py-breakpoint-create-fail.py: New testcase.
gdb/testsuite/ChangeLog:
2016-06-25 Manish Goregaokar <manish@mozilla.com>
PR gdb/20239
* gdb.rust/simple.rs: Add more tests for printing NonZero enums.
* gdb.rust/simple.exp: Add test expectations for new NonZero tests.
GDB computes structure byte offsets using a 32 bit integer. And,
first it computes the offset in bits and then converts to bytes. The
result is that any offset that if 512K bytes or larger overflows.
This patch changes GDB to use LONGEST for such calculations.
PR gdb/17520 Structure offset wrong when 1/4 GB or greater.
* c-lang.h: Change all parameters, variables, and struct or union
members used as struct or union fie3ld offsets from int to
LONGEST.
* c-valprint.c: Likewise.
* cp-abi.c: Likewise.
* cp-abi.h: Likewise.
* cp-valprint.c: Likewise.
* d-valprint.c: Likewise.
* dwarf2loc.c: Likewise.
* eval.c: Likewise.
* extension-priv.h: Likewise.
* extension.c: Likewise.
* extension.h: Likewise.
* findvar.c: Likewise.
* gdbtypes.h: Likewise.
* gnu-v2-abi.c: Likewise.
* gnu-v3-abi.c: Likewise.
* go-valprint.c: Likewise.
* guile/guile-internal.h: Likewise.
* guile/scm-pretty-print.c: Likewise.
* jv-valprint.c Likewise.
* opencl-lang.c: Likewise.
* p-lang.h: Likewise.
* python/py-prettyprint.c: Likewise.
* python/python-internal.h: Likewise.
* spu-tdep.c: Likewise.
* typeprint.c: Likewise.
* valarith.c: Likewise.
* valops.c: Likewise.
* valprint.c: Likewise.
* valprint.h: Likewise.
* value.c: Likewise.
* value.h: Likewise.
* p-valprint.c: Likewise.
* c-typeprint.c (c_type_print_base): When printing offset, use
plongest, not %d.
* gdbtypes.c (recursive_dump_type): Ditto.
PR gdb/16483 notes that the output of "info frame-filters" is quite
voluminous. In particular it prints an entry for each objfile, even if
only to say that the objfile does not have any associated frame filters.
I think it's better to only print output when there is a frame filter.
There's nothing worth doing with the no-frame-filter information, and
limiting the output makes it much more readable.
Built and regtested on x86-64 Fedora 23.
2016-06-23 Tom Tromey <tom@tromey.com>
PR gdb/16483:
* python/lib/gdb/command/frame_filters.py
(InfoFrameFilter.list_frame_filters): Rename to print_list. Print
nothing if no filters found. Return value indicating whether
filters were printed.
(InfoFrameFilter.print_list): Remove.
(InfoFrameFilter.invoke): Print message if no frame filters
found.
2016-06-23 Tom Tromey <tom@tromey.com>
PR gdb/16483:
* gdb.python/py-framefilter.exp: Add "info frame-filter" test
before any filters are loaded.
Output for Fortran derived classes is like:
"( 9, 'abc')"
with this changes the output is changed to:
"( lucky_number = 9, letters = 'abc')"
2016-06-21 Walfred Tedeschi <walfred.tedeschi@intel.com>
* f-valprint.c (f_val_print): Add field names for printing
derived types fields.
gdb/testsuite:
* gdb.fortran/derived-type.exp (print q): Add fields to the output.
* gdb.fortran/vla-type.exp (print twov): Fix vla tests with
structs.
* gdb.fortran/derived-type-function.exp: New file.
* gdb.fortran/derived-type-function.f90: New file.
This adds a test that uses new-ui to create a secondary console, and
then runs some basic smoke tests. It ensures that:
- synchronous commands send output to the UI that initiated it
- asynchronous events like breakpoint hits are reported on all
consoles.
- "new-ui" without arguments doesn't crash.
- The "new-ui" command doesn't repeat.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.base/new-ui.exp: New file.
* lib/mi-support.exp (switch_gdb_spawn_id): Move to ...
* lib/gdb.exp (switch_gdb_spawn_id): ... here.
(with_spawn_id): New procedure.
The following scenario:
- gdb started in normal CLI mode.
- separate MI channel created with new-ui
- inferior output redirected with the "set inferior-tty" command.
- use -exec-run in the MI channel to run the inferior
is presently mishandled.
When we create the inferior, in fork-child.c, right after vfork, we'll
close all the file descriptors in the vfork child, and then dup the
tty to file descriptors 0/1/2, create a session, etc. Note that when
we close all descriptors, we close the file descriptors behind
gdb_stdin/gdb_stdout/gdb_stderr of all secondary UIs... So if
anything goes wrong in the child and it calls warning/error, it'll end
up writting to the current UI's stdout/stderr streams, which are
backed by file descriptors that have since been closed. Because this
happens in a vfork region, the corresponding stdin/stdout/stderr in
the parent/gdb end up corrupted.
The fix is to switch to the main UI right after the vfork, so that
gdb_stdin/gdb_stdout/gdb_stderr are correctly mapped to
stdin/stdout/stderr (and thus to file descriptors 0/1/2), so this code
works as it has always worked.
(Technically, we're doing a lot of stuff we shouldn't be doing after a
vfork, while we should only be calling async-signal-safe functions.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* fork-child.c (fork_inferior): Switch the child to the main UI
right after vfork. Save/restore the current UI in the parent.
Flush outputs of the main UI instead of the current UI.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-exec-run.exp: New file.
mi-break.exp regresses when tested with MI running on a secondary UI,
with RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1".
The problem is simply that the test sets a breakpoint, and attaches
"print" commands to the breakpoint. Since breakpoint commands always
run with the main UI as current UI, the breakpoint command's output
goes to the main UI. So we need to tweak the test to expect it there.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-break.exp (test_breakpoint_commands): Always expect
breakpoint command's output on the main UI.
(test_break): New procedure, factored out from calls in the top
level.
(top level): Use foreach_with_prefix to test MI as main UI and as
separate UI.
Testing with:
make check RUNTESTFLAGS="SEPARATE_MI_TTY=1"
shows this, in gdb.mi/mi-watch.exp:
-*stopped,reason="watchpoint-scope",wpnum="2",frame={addr="0x00000000004005cb",
+*stopped,frame={addr="0x00000000004005cb",
(...)
-PASS: gdb.mi/mi-watch.exp: hw: watchpoint trigger
+FAIL: gdb.mi/mi-watch.exp: hw: watchpoint trigger (unknown output after running)
That is, we lose the "watchpoint-scope" output on the MI UI.
This commit fixes it, and makes the test run with MI running as both
main UI and separate UI.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* breakpoint.c (watchpoint_check): Send watchpoint-deleted output
to all UIs.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.mi/mi-watch.exp (test_watchpoint_creation_and_listing)
(test_awatch_creation_and_listing)
(test_rwatch_creation_and_listing, test_watchpoint_triggering):
Remove 'type' parameter.
(test_watchpoint_all): New parameter mi_mode. Remove
with_test_prefix.
(top level): Use foreach_with_prefix, and add main/separate UI MI
testing axis.
With this, a specific test may can start GDB with MI on a separate UI
by using:
mi_gdb_start separate-mi-tty
In addition, it's also possible to run the whole testsuite with MI on
a separate tty, with:
make check RUNTESTFLAGS="FORCE_SEPARATE_MI_TTY=1"
gdb_main_spawn_id and mi_spawn_id are added so that tests may expect
output from either channel.
While at it, inferior_spawn_id was not being cleared when gdb exits,
unlike the other spawn ids, thus a test that starts gdb more than once
would end up using a stale spawn id.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* README (Testsuite Parameters): Document FORCE_SEPARATE_MI_TTY.
* lib/gdb.exp (default_gdb_exit): Clear inferior_spawn_id.
* lib/mi-support.exp (mi_uncatched_gdb_exit): Unset
gdb_main_spawn_id, mi_spawn_id, unset inferior_spawn_id.
(gdb_main_spawn_id, mi_spawn_id): Declare and
comment.
(mi_create_inferior_pty): New procedure,
factored out from default_mi_gdb_start.
(switch_gdb_spawn_id, mi_gdb_start_separate_mi_tty): New
procedures.
(default_mi_gdb_start): Call mi_gdb_start_separate_mi_tty if the
separate-mi-tty option is specified, or SEPARATE_MI_TTY is set.
Use mi_create_inferior_pty.
(mi_gdb_start): Use eval to pass down args list.
I noticed that if we step into an inline function, step_1 never
reaches proceed, and thus nevers sets the thread's
tp->control.command_interp. Because of that,
should_print_stop_to_console fails to determine that is should print
stop output to the console.
The fix is to set the thread's command_interp earlier. However, I
realized that we can move that field to the thread_fsm, given that its
lifetime is exactly the same as thread_fsm. So the patch plumbs all
fsms constructors to take the command interp and store it in the
thread_fsm.
We can see the fix in action, with e.g., the gdb.opt/inline-cmds.exp
test, and issuing a step when stopped at line 67:
&"s\n"
^running
*running,thread-id="all"
(gdb)
~"67\t result = func2 ();\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004004d0",func="main",args=[],file="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",line="67"},thread-id="1",stopped-threads="all",core="0"
(gdb)
s
&"s\n"
^running
*running,thread-id="all"
(gdb)
+ ~"func2 () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c:67\n"
+ ~"67\t result = func2 ();\n"
*stopped,reason="end-stepping-range",frame={addr="0x00000000004004d0",func="func2",args=[],file="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",fullname="/home/pedro/gdb/mygit/src/gdb/testsuite/gdb.opt/inline-cmds.c",line="67"},thread-id="1",stopped-threads="all",core="0"
(gdb)
(The inline-cmds.exp command is adjusted to exercise this.)
(Due to the follow_fork change, this also fixes "next N" across a fork
with "set follow-fork child" with "set detach-on-fork on". Commands
that rely on internal breakpoints, like "finish" will still require
more work to migrate breakpoints etc. to the child thread.)
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* breakpoint.c (new_until_break_fsm): Add 'cmd_interp' parameter.
(until_break_fsm_should_stop, until_break_fsm_clean_up): Add
thread parameter.
(until_break_command): Pass command interpreter to thread fsm
ctor.
* cli/cli-interp.c (should_print_stop_to_console): Adjust.
* gdbthread.h (struct thread_control_state) <command_interp>:
Delete field.
* infcall.c (new_call_thread_fsm): Add 'cmd_interp' parameter.
Pass it down.
(call_thread_fsm_should_stop): Add thread parameter.
(call_function_by_hand_dummy): Pass command interpreter to thread
fsm ctor. Pass thread pointer to fsm clean up method.
* infcmd.c: Include interps.h.
(struct step_command_fsm) <thread>: Delete field.
(new_step_command_fsm): Add 'cmd_interp' parameter. Pass it down.
(step_command_fsm_prepare): Remove references to fsm's thread
field.
(step_1): Pass command interpreter to thread
fsm ctor. Pass thread pointer to fsm clean up method.
(step_command_fsm_should_stop, step_command_fsm_clean_up): Add
thread parameter and use it.
(new_until_next_fsm): Add 'cmd_interp' parameter. Pass it down.
(until_next_fsm_should_stop, until_next_fsm_clean_up): Add thread
parameter and use it.
(until_next_command): Pass command interpreter to thread fsm ctor.
(struct finish_command_fsm) <thread>: Delete field.
(finish_command_fsm_ops): Add NULL slot for should_notify_stop.
(new_finish_command_fsm): Add 'cmd_interp' parameter and pass it
down. Remove thread parameter and adjust.
(finish_command_fsm_should_stop, finish_command_fsm_clean_up): Add
thread parameter and use it.
(finish_command): Pass command interpreter to thread fsm ctor.
Don't pass thread.
* infrun.c (follow_fork): Move thread fsm to child fork instead of
command interpreter, only.
(clear_proceed_status_thread): Remove reference to command_interp.
(proceed): Don't record the thread's command interpreter.
(clean_up_just_stopped_threads_fsms): Pass thread to fsm clean_up
method.
(fetch_inferior_event): Pass thread to fsm should_stop method.
* thread-fsm.c (thread_fsm_ctor): Add 'cmd_interp' parameter.
Store it.
(thread_fsm_clean_up, thread_fsm_should_stop): Add thread
parameter and pass it down.
* thread-fsm.h (struct thread_fsm) <command_interp>: New field.
(struct thread_fsm_ops) <clean_up, should_stop>: Add thread
parameter.
(thread_fsm_ctor): Add 'cmd_interp' parameter.
(thread_fsm_clean_up, thread_fsm_should_stop): Add thread
parameter.
* thread.c (thread_cancel_execution_command): Pass thread to
thread fsm clean_up method.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.opt/inline-cmds.c: Add "set mi break here" marker.
* gdb.opt/inline-cmds.exp: Add MI tests.
Due to the way that readline's API works (based on globals), we can
only have one instance of readline in a process. So the goal of this
patch is to only allow editing in the main UI, and make sure that only
one UI calls into readline. Some MI paths touch readline variables
currently, which is bad as that is changing variables that matter for
the main console UI. This patch fixes those.
This actually fixes a nasty bug -- starting gdb in MI mode ("gdb
-i=mi"), and then doing "set editing on" crashes GDB, because MI is
not prepared to use readline:
set editing on
&"set editing on\n"
=cmd-param-changed,param="editing",value="on"
^done
(gdb)
p 1
readline: readline_callback_read_char() called with no handler!
Aborted (core dumped)
The fix for that was to add an interp_proc method to query the
interpreter whether it actually supports editing. New test included.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
PR mi/20034
* cli/cli-interp.c: Include cli-interp.h and event-top.h.
(cli_interpreter_resume): Pass 1 to gdb_setup_readline. Set the
UI's input_handler here.
(cli_interpreter_supports_command_editing): New function.
(cli_interp_procs): Install it.
* cli/cli-interp.h: New file.
* event-top.c (async_command_editing_p): Rename to ...
(set_editing_cmd_var): ... this.
(change_line_handler): Add parameter 'editing', and use it. Bail
early if the interpreter doesn't support editing. Don't touch
readline state if editing is off.
(gdb_rl_callback_handler_remove, gdb_rl_callback_handler_install)
(gdb_rl_callback_handler_reinstall): Assert the current UI is the
main UI.
(display_gdb_prompt): Don't call gdb_rl_callback_handler_remove if
not using readline. Check whether the current UI is using command
editing instead of checking the async_command_editing_p global.
(set_async_editing_command): Delete.
(gdb_setup_readline): Add 'editing' parameter. Only allow editing
on the main UI. Don't touch readline state if editing is off.
(gdb_disable_readline): Don't touch readline state if editing is
off.
* event-top.h (gdb_setup_readline): Add 'int' parameter.
(set_async_editing_command): Delete declaration.
(change_line_handler, command_line_handler): Declare.
(async_command_editing_p): Rename to ...
(set_editing_cmd_var): ... this.
* infrun.c (reinstall_readline_callback_handler_cleanup): Check
whether the current UI has editing enabled rather than checking
the async_command_editing_p global.
* interps.c (interp_supports_command_editing): New function.
* interps.h (interp_supports_command_editing_ftype): New typedef.
(struct interp_procs) <supports_command_editing_proc>: New field.
(interp_supports_command_editing): Declare.
* mi/mi-interp.c (mi_interpreter_resume): Pass 0 to
gdb_setup_readline. Don't clear the async_command_editing_p
global. Update comments.
* top.c (gdb_readline_wrapper_line, gdb_readline_wrapper): Check
whether the current UI has editing enabled rather than checking
the async_command_editing_p global. Don't touch readline state if
editing is off.
(undo_terminal_modifications_before_exit): Switch to the main UI.
Unconditionally call gdb_disable_readline.
(set_editing): New function.
(show_async_command_editing_p): Rename to ...
(show_editing): ... this. Show the state of the current UI.
(_initialize_top): Adjust.
* top.h (struct ui) <command_editing>: New field.
* tui/tui-interp.c: Include cli/cli-interp.h.
(tui_resume): Pass 1 to gdb_setup_readline. Set the UI's
input_handler.
(tui_interp_procs): Install
cli_interpreter_supports_command_editing.
* tui/tui-io.c (tui_getc): Check whether the current UI has
editing enabled rather than checking the async_command_editing_p
global.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
PR mi/20034
* gdb.mi/mi-editing.exp: New file.
Looking at testsuite results, I noticed this warning in an MI test:
~"\nCatchpoint "
~"2, "
&"warning: failed to get exception name: No definition of \"e.full_name\" in current context.\n"
~"exception at 0x000000000040192d in foo () at /home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb:20\n"
~"20\t raise Constraint_Error; -- SPOT1\n"
*stopped,reason="breakpoint-hit",disp="keep",bkptno="2",exception-name="CONSTRAINT_ERROR",frame={addr="0x000000000040192d",func="foo",args=[],file="/home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb",fullname="/home/pedro/brno/pedro/gdb/mygit/src/gdb/testsuite/gdb.ada/mi_catch_ex/foo.adb",line="20"},thread-id="1",stopped-threads="all",core="5"
(gdb)
PASS: gdb.ada/mi_catch_ex.exp: continue until CE caught by all-exceptions catchpoint
The problem is that:
- MI prints the breakpoint hit twice: once on the MI stream;
another time on the console stream.
- After printing the Ada catchpoint hit, gdb selects a non-current
frame, from within the catchpoint's print_it routine.
So the second time the breakpoint is printed, the selected frame is no
longer the current frame, and then evaluating e.full_name in
ada_exception_name_addr fails.
This commit fixes the problem and enhances the gdb.ada/mi_catch_ex.exp
test to make sure the catchpoint hit is printed correctly on the
console stream too.
gdb/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* ada-lang.c (ada_exception_name_addr_1): Add comment.
(print_it_exception): Select the current frame.
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.ada/mi_catch_ex.exp (continue_to_exception): New procedure.
(top level): Use it instead of mi_execute_to.
Similarly to 5068630ad3
(gdb.python/py-events.exp and normal_stop observers ordering) [1],
this commit makes the gdb.python/py-mi-events.exp test not rely on
order in which MI and Python observers run, or even on where each
observer sends its output to.
This shows up as a problem when testing with MI running as a separate
terminal, for example, where Python event output and MI output go to
different channels, even. But in any case, relying on the order in
which observers run is always going to be fragile.
The fix is to save the string output in the handlers in some variables
and then having MI print them explicitly, instead of printing them
directly from the Python events.
Tested on x86_64 Fedora 23.
https://sourceware.org/ml/gdb-patches/2015-07/msg00290.html
gdb/testsuite/ChangeLog:
2016-06-21 Pedro Alves <palves@redhat.com>
* gdb.python/py-mi-events-gdb.py (stop_handler_str)
(cont_handler_str): New.
(signal_stop_handler): Set stop_handler_str instead of printing to
stdout.
(continue_handler): Set cont_handler_str instead of printing to
stdout.
* gdb.python/py-mi-events.exp: Ues mi_execute_to instead of
mi_send_resuming_command. Print stop_handler_str and
cont_handler_str instead of expecting the python events print
directly.
Originally intended to be committed on 2013-01-17 in
675921c059 (Test case for the
jit-reader), but by mistake the files were not added. Fortunately
they still work.
gdb/testsuite/ChangeLog:
2016-06-17 Sanjoy Das <sanjoy@playingwithpointers.com>
* gdb.base/jit-reader.exp: New file.
* gdb.base/jithost.c: New file.
* gdb.base/jithost.h: New file.
* gdb.base/jitreader.c : New file.
* gdb.base/jit-protocol.h: New file.
This patch extends step-over-syscall.exp by setting different values to
detach-on-fork and follow-fork.
gdb/testsuite:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (break_cond_on_syscall): New
parameters follow_fork and detach_on_fork. Set follow-fork-mode
and detach-on-fork. Adjust tests.
(top level): Invoke break_cond_on_syscall with combinations of
syscall, follow-fork-mode and detach-on-fork.
This patch fixes a GDBserver crash when one thread is stepping over
a syscall instruction which is exit. Step-over isn't finished due
to the exit, but GDBserver doesn't clean up the state of step-over,
so in the wait next time, GDBserver will wait on step_over_bkpt,
which is already exited, and GDBserver crashes because
'requested_child' is NULL. See gdbserver logs below,
Need step over [LWP 14858]? yes, found breakpoint at 0x2aaaaad91307^M
proceed_all_lwps: found thread 14858 needing a step-over^M
Starting step-over on LWP 14858. Stopping all threads^M
>>>> entering void stop_all_lwps(int, lwp_info*)
....
<<<< exiting void stop_all_lwps(int, lwp_info*)^M
Done stopping all threads for step-over.^M
pc is 0x2aaaaad91307^M
Writing 0f to 0x2aaaaad91307 in process 14858^M
Could not find fast tracepoint jump at 0x2aaaaad91307 in list (uninserting).^M
pending reinsert at 0x2aaaaad91307^M
step from pc 0x2aaaaad91307^M
Resuming lwp 14858 (step, signal 0, stop not expected)^M
# Start step-over for LWP 14858
>>>> entering ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)
....
LLFE: 14858 exited.
...
<<<< exiting ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)
# LWP 14858 exited
.....
>>>> entering ptid_t linux_wait_1(ptid_t, target_waitstatus*, int)^M
linux_wait_1: [<all threads>]^M
step_over_bkpt set [LWP 14858.14858], doing a blocking wait
# but step_over_bkpt is still LWP 14858, which is wrong
The fix is to finish step-over if it is ongoing, and unsuspend other
threads. Without the fix in linux-low.c, GDBserver will crash in
with running gdb.base/step-over-exit.exp.
gdb/gdbserver:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* linux-low.c (unsuspend_all_lwps): Declare.
(linux_low_filter_event): If thread exited, call finish_step_over.
If step-over is finished, unsuspend other threads.
gdb/testsuite:
2016-06-17 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-exit.c: New.
* gdb.base/step-over-exit.exp: New.
If a target does not support making function calls from GDB then in a
number of test files, we currently report an XFAIL and skip some, or all
of the tests. This commit changes the XFAIL to an UNSUPPORTED as this
seems more appropriate in these cases.
Some of the tests used bug ID 2416 to be reported in the XFAIL. In the
current GDB bugzilla bug 2416 has nothing to do with calling target
functions from GDB.
gdb/testsuite/ChangeLog:
* gdb.base/call-ar-st.exp: Report unsupported rather than xfail
for unsupported target features.
* gdb.base/call-rt-st.exp: Likewise.
* gdb.base/call-sc.exp: Likewise.
* gdb.base/call-signal-resume.exp: Likewise.
* gdb.base/call-strs.exp: Likewise.
* gdb.base/callexit.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/printcmds.exp: Likewise.
* gdb.base/ptype.exp: Likewise.
* gdb.base/structs.exp: Likewise.
* gdb.base/unwindonsignal.exp: Likewise.
* gdb.cp/gdb2495.exp: Likewise.
* gdb.cp/templates.exp: Likewise.
* gdb.cp/virtfunc.exp: Likewise.
* gdb.threads/hand-call-in-threads.exp: Likewise.
* gdb.threads/interrupted-hand-call.exp: Likewise.
* gdb.threads/thread-unwindonsignal.exp: Likewise.
PR rust/20110 concerns the type of an integer constant that is too
large for "i32", the default integer type. This patch changes the
type of such a constant to i64. This is important because such values
are often addresses, so truncating them by default is unfriendly.
Built and regtested on x86-64 Fedora 23.
2016-06-10 Tom Tromey <tom@tromey.com>
PR rust/20110:
* rust-exp.y (lex_number): Don't truncate large numbers to i32.
2016-06-10 Tom Tromey <tom@tromey.com>
PR rust/20110:
* gdb.rust/expr.exp: Add test for integer constant larger than
i32.
Non-local references in nested functions are usually implemented
by using DWARF static link. This feature was added
with commit 63e43d3aed
(DWARF: handle non-local references in nested functions) but
a testcase was missing in Fortran.
2016-06-10 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Testsuite/Changelog:
* gdb.fortran/nested-funcs.exp: New.
* gdb.fortran/nested-funcs.f90: New.
This change adds support for specifying a negative repeat count to
all the formats of the 'x' command to examine memory backward.
A new testcase 'examine-backward' is added to cover this new feature.
Here's the example output from the new feature:
<format 'i'>
(gdb) bt
#0 Func1 (n=42, p=0x40432e "hogehoge") at main.cpp:5
#1 0x00000000004041fa in main (argc=1, argv=0x7fffffffdff8) at main.cpp:19
(gdb) x/-4i 0x4041fa
0x4041e5 <main(int, char**)+11>: mov %rsi,-0x10(%rbp)
0x4041e9 <main(int, char**)+15>: lea 0x13e(%rip),%rsi
0x4041f0 <main(int, char**)+22>: mov $0x2a,%edi
0x4041f5 <main(int, char**)+27>: callq 0x404147
<format 'x'>
(gdb) x/-4xw 0x404200
0x4041f0 <main(int, char**)+22>: 0x00002abf 0xff4de800 0x76e8ffff 0xb8ffffff
(gdb) x/-4
0x4041e0 <main(int, char**)+6>: 0x7d8910ec 0x758948fc 0x358d48f0 0x0000013e
gdb/ChangeLog:
* NEWS: Mention that GDB now supports a negative repeat count in
the 'x' command.
* printcmd.c (decode_format): Allow '-' in the parameter
"string_ptr" to accept a negative repeat count.
(find_instruction_backward): New function.
(read_memory_backward): New function.
(integer_is_zero): New function.
(find_string_backward): New function.
(do_examine): Use new functions to examine memory backward.
(_initialize_printcmd): Mention that 'x' command supports a negative
repeat count.
gdb/doc/ChangeLog:
* gdb.texinfo (Examining Memory): Document negative repeat
count in the 'x' command.
gdb/testsuite/ChangeLog:
* gdb.base/examine-backward.c: New file.
* gdb.base/examine-backward.exp: New file.
Eclipse CDT now supports enabling execution recording using two methods
(full and btrace) and both formats for btrace (bts and pt). In the
event that recording is enabled behind the back of the GUI (by the user
on the command line, or a script), we need to know which method/format
are being used, so it can be correctly reflected in the interface. This
patch adds this information to the =record-started async record.
Before:
=record-started,thread-group="i1"
After:
=record-started,thread-group="i1",method="btrace",format="bts"
=record-started,thread-group="i1",method="btrace",format="pt"
=record-started,thread-group="i1",method="full"
The "format" field is only present when the current method supports
multiple formats (only the btrace method as of now).
gdb/ChangeLog:
* NEWS: Mention the new fields in =record-started.
* common/btrace-common.h (btrace_format_short_string): New function
declaration.
* common/btrace-common.c (btrace_format_short_string): New
function.
* mi/mi-interp.c (mi_record_changed): Output method and format
fields in the =record-started record.
* record-btrace.c (record_btrace_open): Adapt record_changed
notification.
* record-full.c (record_full_open): Likewise.
* record.c (cmd_record_stop): Likewise.
gdb/doc/ChangeLog:
* gdb.texinfo (GDB/MI Async Records): Document method and
format fields in =record-started.
* observer.texi (record_changed): Add method and format
parameters.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-record-changed.exp: Adjust =record-started output
matching.
This fixes PR python/18984.
The bug is that gdbpy_solib_name uses GDB_PY_LL_ARG, whereas it should
use GDB_PY_LLU_ARG to avoid overflow.
Built and tested on x86-64 Fedora 23.
2016-06-02 Tom Tromey <tom@tromey.com>
PR python/18984:
* python/python.c (gdbpy_solib_name): Use GDB_PY_LLU_ARG.
2016-06-02 Tom Tromey <tom@tromey.com>
PR python/18984:
* gdb.python/py-shared.exp: Add solib_name test.
https://sourceware.org/bugzilla/show_bug.cgi?id=19893
I've traced the main source of the problem to pieced_value_funcs.coerce_ref not being
implemented. Since gdb always assumes references are implemented as pointers, this
causes it to think that it's dealing with a NULL pointer, thus breaking any operations
involving synthetic references.
What I did here was implementing pieced_value_funcs.coerce_ref using some of the synthetic
pointer handling code from indirect_pieced_value, as Pedro suggested. I also made a few
adjustments to the reference printing code so that it correctly shows either the address
of the referenced value or (if it's non-addressable) the "<synthetic pointer>" string.
I also wrote some unit tests based on Dwarf::assemble; these took a while to make
because in most cases I needed a synthetic reference to a physical variable. Additionally,
I started working on a unit test for classes that have a vtable, but ran into a few issues
so that'll probably go in a future patch. One thing that should definitely be fixed is that
proc function_range (called for MACRO_AT_func) will always try to compile/link using gcc
with the default options instead of g++, thus breaking C++ compilations that require e.g. libstdc++.
gdb/ChangeLog:
* dwarf2loc.c (coerce_pieced_ref, indirect_synthetic_pointer,
fetch_const_value_from_synthetic_pointer): New functions.
(indirect_pieced_value): Move lower half to indirect_synthetic_pointer.
(pieced_value_funcs): Implement coerce_ref.
* valops.c (value_addr): Call coerce_ref for synthetic references.
* valprint.c (valprint_check_validity): Return true for synthetic
references. Also, don't show "<synthetic pointer>" if they reference
addressable values.
(generic_val_print_ref): Handle synthetic references. Also move some
code to print_ref_address.
(print_ref_address, get_value_addr_contents): New functions.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implref.exp: Rename to...
* gdb.dwarf2/implref-const.exp: ...this. Also add more test statements.
* gdb.dwarf2/implref-array.c: New file.
* gdb.dwarf2/implref-array.exp: Likewise.
* gdb.dwarf2/implref-global.c: Likewise.
* gdb.dwarf2/implref-global.exp: Likewise.
* gdb.dwarf2/implref-struct.c: Likewise.
* gdb.dwarf2/implref-struct.exp: Likewise.
This patch adds tests for emit operations with 64 bit values. It takes
special care to avoid mistakes that one could make on a 32bit architecture
using 64bit values.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add 64bit tests.
This patch add variable length tests for emit_ref by reading the variable
passed as argument of 8 to 64 bit.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.c (marker): Adapt signature to 8 to 64
bits types.
(main): Adapt to 8 to 64 bits types.
* gdb.trace/trace-condition.exp: Add new tests.
This patch moves conditional tests that were done in ftrace.exp to
trace-condition.exp.
Note that emit_ref is now tested by the anarg local variable there is no
need to test the register directly.
All emit calls have been tested using asserts before / after the move, to
ensure that the tests cover the same functions.
Note that these function were not covered before and are still not:
emit_gt_goto, emit_lt_goto, emit_pop, emit_unsigned_less.
gdb/testsuite/ChangeLog:
* gdb.trace/ftrace.exp (test_ftrace_condition): Remove.
Move condition tests...
* gdb.trace/trace-condition.exp: Here.
In trace-condition.exp, tests are done by doing a conditional tracepoint
and validating that the trace contains all the frames that could be
collected if that condition is true.
E.g. test_tracepoints $trace_command "21 + 21 == 42" 10
This will always return true and collect the 10 frames possible to collect
with the test program.
However, if the condition evaluation is broken such that the condition is
unconditional we will not notice this problem.
This patch adds counter-cases to such conditions like so:
$trace_command "21 + 11 == 42" 0
This way such a problem would be noticed.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-condition.exp: Add counter-case tests.
Local variables in lambdas are not accessible
https://sourceware.org/bugzilla/show_bug.cgi?id=15231
GDB: read_lexical_block_scope
/* Ignore blocks with missing or invalid low and high pc attributes. */
[...]
if (!dwarf2_get_pc_bounds (die, &lowpc, &highpc, cu, NULL))
return;
But sometimes there is:
FAIL: gcc-5.3.1-6.fc23.x86_64
<2><92>: Abbrev Number: 11 (DW_TAG_lexical_block)
<3><9c>: Abbrev Number: 13 (DW_TAG_structure_type)
<9d> DW_AT_name : (indirect string, offset: 0x3c): <lambda()>
[...]
Where DW_TAG_lexical_block has no attributes. Such whole subtree is currently
dropped by GDB while I think it should just import all its children DIEs.
It even XFAIL->XPASSes gdb.ada/out_of_line_in_inlined.exp:
commit 0fa7fe506c
Author: Joel Brobecker <brobecker@adacore.com>
out of line functions nested inside inline functions.
So I have removed that xfail.
gdb/ChangeLog
2016-05-30 Jan Kratochvil <jan.kratochvil@redhat.com>
PR c++/15231
* dwarf2read.c (enum pc_bounds_kind): Add PC_BOUNDS_INVALID.
(process_psymtab_comp_unit_reader, read_func_scope): Adjust callers.
(read_lexical_block_scope): Import DIEs from bare DW_TAG_lexical_block.
(read_call_site_scope): Adjust callers.
(dwarf2_get_pc_bounds): Implement pc_bounds_invalid.
(dwarf2_get_subprogram_pc_bounds, get_scope_pc_bounds): Adjust callers.
gdb/testsuite/ChangeLog
2016-05-30 Jan Kratochvil <jan.kratochvil@redhat.com>
PR c++/15231
* gdb.ada/out_of_line_in_inlined.exp: Remove xfails.
* gdb.dwarf2/dw2-lexical-block-bare.exp: New file.
If the testsuite is run with a DejaGnu version that predates the fix
from last year:
[PATCH] DejaGnu kills the wrong process due to PID-reuse races
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00005.html
... gdb.threads/attach-many-short-lived-threads.exp fails randomly,
often. Other tests randomly fail due to that issue too, but this one
is _much_ more exposed.
DejaGnu 1.6 was released meanwhile, which includes that DejaGnu fix,
and also some distros backported the fix too.
So skip the test when run with older/broken DejaGnus.
gdb/testsuite/ChangeLog:
2016-05-27 Pedro Alves <palves@redhat.com>
* gdb.threads/attach-many-short-lived-threads.exp (bad_dejagnu):
New procedure.
(top level): Call it, and bail out of DejaGnu is known to be bad.
Assume that we have a C program like this:
struct foo_type
{
int var;
} foo;
struct foo_type *foo_ptr = &foo;
int
main ()
{
return foo_ptr->var;
}
Then GDB should be able to evaluate the following, however, it currently
does not:
(gdb) start
...
(gdb) whatis &(foo_ptr->var)
Attempt to take address of value not located in memory.
The problem is that in EVAL_AVOID_SIDE_EFFECTS mode,
eval.c:evaluate_subexp_standard always returns a not_lval value as the
result for a STRUCTOP_PTR operation. As a consequence, the rest of
the code believes that one cannot take the address of the returned
value.
This patch fixes STRUCTOP_PTR handling so that the VALUE_LVAL
attribute for the returned value is properly initialized. After this
change, the above session becomes:
(gdb) start
...
(gdb) whatis &(foo_ptr->var)
type = int *
This commit is largely the same as commit 2520f728b7 (Forward
VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT) but applied
to STRUCTOP_PTR rather than STRUCTOP_STRUCT. Both of these commits are
building on top of commit ac1ca910d7 (Fixes for PR exp/15364).
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard): If EVAL_AVOID_SIDE_EFFECTS
mode, forward the VALUE_LVAL attribute to the returned value in
the STRUCTOP_PTR case.
gdb/testsuite/ChangeLog:
* gdb.base/whatis.c: Extend the test case.
* gdb.base/whatis.exp: Add additional tests.
Variable "show" was hardcoded to zero for pointer and reference types.
This implementation didn't allow a correct "whatis" print
for those types and results in same output for "ptype" and "whatis".
Before:
(gdb) whatis t3p
type = PTR TO -> ( Type t3
integer(kind=4) :: t3_i
Type t2 :: t2_n
End Type t3 )
After:
(gdb) whatis t3p
type = PTR TO -> ( Type t3 )
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Replace 0 by show.
gdb/testsuite/Changelog:
* gdb.fortran/type.f90: Add pointer variable.
* gdb.fortran/whatis_type.exp: Add whatis/ptype of pointers.
As as result of printing only the outer elements of nested structures,
some testcases have to be added to check for corner cases with VLA's.
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.exp: Access elements in nested structs.
According to the typeprint's description, the level of details is
decreased by one for the typeprint of elements of a structure.
Before:
(gdb) ptype t3v
type = Type t3
integer(kind=4) :: t3_i
Type t2
integer(kind=4) :: t2_i
Type t1
integer(kind=4) :: t1_i
real(kind=4) :: t1_r
End Type t1 :: t1_n
End Type t2 :: t2_n
End Type t3
After:
(gdb) ptype t3v
type = Type t3
integer(kind=4) :: t3_i
Type t2 :: t2_n
End Type t3
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Decrease show by one.
gdb/testsuite/Changelog:
* gdb.fortran/type.f90: Add nested structures.
* gdb.fortran/whatis-type.exp: Whatis/ptype nested structures.
* gdb.fortran/derived-type.exp: Adapt expected output.
* gdb.fortran/vla-type.exp: Adapt expected output.
According to the typeprint's description, elements of a structure
should not be printed when show is < 1.
This variable is also used to distinguish the level of details
between "ptype" and "whatis" expressions.
Before:
(gdb) whatis t1v
type = Type t1
integer(kind=4) :: t1_i
real(kind=4) :: t1_r
End Type t1
After:
(gdb) whatis t1v
type = Type t1
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Don't print fields when show < 0.
gdb/testsuite/Changelog:
* gdb.fortran/whatis_type.exp: Adapt expected output.
Level of indentation was not proper handled when printing
the elements type's name.
Before:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
After:
type = Type t1
integer(kind=4) :: var_1
integer(kind=4) :: var_2
End Type t1
2016-05-25 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-typeprint.c (f_type_print_base): Take print level into account.
gdb/testsuite/Changelog:
* gdb.fortran/print_type.exp: Fix expected output.
* gdb.fortran/whatis_type.exp: Fix expected output.
This patch fixes PR python/17386.
The bug is that gdb.Value does not implement the Python __index__
method. This method is needed to convert a Python object to an index
and is used by various operations in Python, such as indexing an
array.
The fix is to implement the nb_index method for gdb.Value.
nb_index was added in Python 2.5. I don't have a good way to test
Python 2.4, but I made an attempt to accomodate it.
I chose to use valpy_long in all cases because this simplifies porting
to Python 3, and because there didn't seem to be any harm.
Built and regtested on x86-64 Fedora 23.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* python/py-value.c (value_object_as_number): Add
nb_inplace_floor_divide, nb_inplace_true_divide, nb_index.
2016-05-24 Tom Tromey <tom@tromey.com>
PR python/17386:
* gdb.python/py-value.exp (test_value_numeric_ops): Add tests that
use value as an index.
PR python/17981 notes that gdb.breakpoints() returns None when there
are no breakpoints; whereas an empty list or tuple would be more in
keeping with Python and the documentation.
This patch fixes the bug by changing the no-breakpoint return to make
an empty tuple.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* python/py-breakpoint.c (gdbpy_breakpoints): Return a new tuple
when there are no breakpoints.
2016-05-23 Tom Tromey <tom@tromey.com>
* python.texi (Basic Python): Document gdb.breakpoints return.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/17981:
* gdb.python/py-breakpoint.exp (test_bkpt_basic): Add test for
no-breakpoint case.
When GDB attaches to a process, it looks at the /proc/PID/task/ dir
for all clone threads of that process, and attaches to each of them.
Usually, if there is more than one clone thread, it means the program
is multi threaded and linked with pthreads. Thus when GDB soon after
attaching finds and loads a libthread_db matching the process, it'll
add a thread to the thread list for each of the initially found
lower-level LWPs.
If, however, GDB fails to find/load a matching libthread_db, nothing
is adding the LWPs to the thread list. And because of that, "detach"
hits an internal error:
(gdb) PASS: gdb.threads/clone-attach-detach.exp: fg attach 1: attach
info threads
Id Target Id Frame
* 1 LWP 6891 "clone-attach-de" 0x00007f87e5fd0790 in __nanosleep_nocancel () at ../sysdeps/unix/syscall-template.S:84
(gdb) FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: info threads shows two LWPs
detach
.../src/gdb/thread.c:1010: internal-error: is_executing: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
FAIL: gdb.threads/clone-attach-detach.exp: fg attach 1: detach (GDB internal error)
From here:
...
#8 0x00000000007ba7cc in internal_error (file=0x98ea68 ".../src/gdb/thread.c", line=1010, fmt=0x98ea30 "%s: Assertion `%s' failed.")
at .../src/gdb/common/errors.c:55
#9 0x000000000064bb83 in is_executing (ptid=...) at .../src/gdb/thread.c:1010
#10 0x00000000004c23bb in get_pending_status (lp=0x12c5cc0, status=0x7fffffffdc0c) at .../src/gdb/linux-nat.c:1235
#11 0x00000000004c2738 in detach_callback (lp=0x12c5cc0, data=0x0) at .../src/gdb/linux-nat.c:1317
#12 0x00000000004c1a2a in iterate_over_lwps (filter=..., callback=0x4c2599 <detach_callback>, data=0x0) at .../src/gdb/linux-nat.c:899
#13 0x00000000004c295c in linux_nat_detach (ops=0xe7bd30, args=0x0, from_tty=1) at .../src/gdb/linux-nat.c:1358
#14 0x000000000068284d in delegate_detach (self=0xe7bd30, arg1=0x0, arg2=1) at .../src/gdb/target-delegates.c:34
#15 0x0000000000694141 in target_detach (args=0x0, from_tty=1) at .../src/gdb/target.c:2241
#16 0x0000000000630582 in detach_command (args=0x0, from_tty=1) at .../src/gdb/infcmd.c:2975
...
Tested on x86-64 Fedora 23. Also confirmed the test passes against
gdbserver with "maint set target-non-stop".
gdb/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* linux-nat.c (attach_proc_task_lwp_callback): Mark the lwp
resumed, and add the thread to GDB's thread list.
testsuite/ChangeLog:
2016-05-24 Pedro Alves <palves@redhat.com>
PR gdb/19828
* gdb.threads/clone-attach-detach.c: New file.
* gdb.threads/clone-attach-detach.exp: New file.
This patch fixes a syntax error which caused a failure in
annota-input-while-running.exp to crash the test suite runner.
2016-05-24 Francis Ricci <francisjricci@gmail.com>
* gdb.base/annota-input-while-running.exp: Fix syntax error.
This fixes PR python/19438 and PR python/18393. Both bugs are about
invoking dir() on some Python object implemented by gdb, and getting a
crash.
The crash happens because the dictionary field of these objects was
not initialized. Apparently what happens is that this field can be
lazily initialized by Python when assigning to an attribute; and it
can also be handled ok when using dir() but without __dict__ defined;
but gdb defines __dict__ because this isn't supplied automatically by
Python.
The docs on this seem rather sparse, but this patch works ok.
An alternative might be to lazily create the dictionary in
gdb_py_generic_dict, but I went with this approach because it seemed
more straightforward.
Built and regtested on x86-64 Fedora 23.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* python/py-objfile.c (objfpy_initialize): Initialize self->dict.
* python/py-progspace.c (pspy_initialize): Initialize self->dict.
2016-05-23 Tom Tromey <tom@tromey.com>
PR python/19438, PR python/18393:
* gdb.python/py-progspace.exp: Add "dir" test.
* gdb.python/py-objfile.exp: Add "dir" test.
This patch fixes the errors below:
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb-prologue.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb-prologue: No such file or directory
collect2: error: ld returned 1 exit status
Running /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.arch/thumb2-it.exp ...
gdb compile failed, arm-linux-gnueabihf/bin/ld: cannot open output file /scratch/yao/gdb/build-git/arm-linux-gnueabihf/gdb/testsuite/gdb.arch/thumb2-it: No such file or directory
gdb/testsuite:
2016-05-23 Yao Qi <yao.qi@linaro.org>
* gdb.arch/thumb-prologue.exp: Use standard_testfile.
* gdb.arch/thumb2-it.exp: Likewise.
Add a new test for PR 20039. The test spawns new threads, then tries to
interrupt, continue, and interrupt again. This use case was fixed by
commit 5fe966540d in master, but gdb 7.11
is affected (so if you try it on the gdb-7.11-branch right now, the test
will fail).
New in v2, the test now handles mi-async on mode properly. The failure
was specific to mi-async off, but I don't think it's bad to test the
same thing under async on mode. I added a little hack when running in
async mode to work around bug 20045.
I also removed one continue/interrupt pair, as a single one was enough to
trigger the problem.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-threads-interrupt.c: New file.
* gdb.mi/mi-threads-interrupt.exp: New file.
When doing -exec-run on a freshly started GDB, the only target on the
target stack at the time the dummy one. When mi_async_p is called to
know whether the run should be async, it queries whether the current
target (dummy) supports async, and the answer is no. The fix is to make
the code query the target that will be used for the run, which is not
necessarily the current target.
No regressions in the gdb.mi directory using the unix, native-gdbserver
and native-extended-gdbserver boards. The test doesn't pass when
forcing maint set target-async off, obviously, since it makes mi-async
have no effect. It doesn't seem like other tests are checking for that
eventuality, so I didn't in the new test.
gdb/ChangeLog:
* mi/mi-main.c (run_one_inferior): Use run target to determine
whether to run async or not.
(mi_cmd_exec_run): Likewise.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-async-run.exp: New file.
* gdb.mi/mi-async-run.c: New file.
This updates the gdb test suite for Rust.
2016-05-17 Tom Tromey <tom@tromey.com>
Manish Goregaokar <manishsmail@gmail.com>
* lib/rust-support.exp: New file.
* lib/gdb.exp (skip_rust_tests): New proc.
(build_executable_from_specs): Handle rust.
* lib/future.exp (gdb_find_rustc): New proc.
(gdb_default_target_compile): Handle rust.
* gdb.rust/expr.exp: New file.
* gdb.rust/generics.exp: New file.
* gdb.rust/generics.rs: New file.
* gdb.rust/methods.exp: New file.
* gdb.rust/methods.rs: New file.
* gdb.rust/modules.exp: New file.
* gdb.rust/modules.rs: New file.
* gdb.rust/simple.exp: New file.
* gdb.rust/simple.rs: New file.
I wanted to unit test the Rust lexer, so I added a simple unit testing
command to gdb.
The intent is that self tests will only be compiled into gdb in
development mode. In release mode they simply won't exist. So, this
exposes $development to C code as GDB_SELF_TEST.
In development mode, test functions are registered with the self test
module. A test function is just a function that does some checks, and
throws an exception on failure.
Then this adds a new "maint selftest" command which invokes the test
functions, and a new dejagnu test case that invokes it.
2016-05-17 Tom Tromey <tom@tromey.com>
* NEWS: Add "maint selftest" entry.
* selftest.h: New file.
* selftest.c: New file.
* maint.c: Include selftest.h.
(maintenance_selftest): New function.
(_initialize_maint_cmds): Add "maint selftest" command.
* configure.ac (GDB_SELF_TEST): Maybe define.
* config.in, configure: Rebuild.
* Makefile.in (SFILES): Add selftest.c.
(COMMON_OBS): Add selftest.o.
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.texinfo (Maintenance Commands): Document "maint selftest".
2016-05-17 Tom Tromey <tom@tromey.com>
* gdb.gdb/unittest.exp: New file.
batch-preserve-term-settings.exp fails if the shell prompt isn't $. It
is # in our testing env. In fact, the shell prompt can be anything.
The perfect solution would be "set_board_info shell_prompt" in the
host board file, and use board_info shell_prompt in
batch-preserve-term-settings.exp. This is a little bit overkill to
me, and we still need to figure out the different prompts on different
shells. I also tried to start shell with the prompt preset, but there is
not unique way to set shell prompt in different shells, so I give up.
It is reasonably simple to match either $ or # for the shell prompt, and
we can easily extend it to match other char, like >.
gdb/testsuite:
2016-05-16 Yao Qi <yao.qi@linaro.org>
* gdb.base/batch-preserve-term-settings.exp: Remove variable
shell_prompt. Update shell_prompt_re.
gdb/ChangeLog:
* dwarf2loc.c (dwarf2_find_location_expression): For DWO files still
add base_offset.
gdb/testsuite/ChangeLog:
* lib/dwarf.exp (build_executable_from_fission_assembler): Pass
$options when building executable.
* gdb.dwarf2/fission-loclists-pie.c: New file.
* gdb.dwarf2/fission-loclists-pie.exp: New file.
This test currently uses [is_remote target] to check if the test is
supported. This is not quite correct, as the limitation is actually
that it requires support for "running", ruling out stub-like targets.
Therefore, it should check for use_gdb_stub.
This has no visible effect right now, but it will once we make the
native-gdbserver board non-dejagnu-remote.
gdb/testsuite/ChangeLog:
* gdb.base/solib-display.exp: Check for [use_gdb_stub] instead
of [is_remote target],
This patch introduces the use_gdb_stub procedure, which allows getting
the right value of the use_gdb_stub variable/property in any all
situations.
When calling it before the $use_gdb_stub global variable has been set,
it will return the value of the use_gdb_stub property from the board
file. This happens when tests want to bail out early (even before gdb
has been started) when the current test setup is a stub.
Otherwise, it returns the value of the $use_gdb_stub global.
It's possible for these two to differ when a test file overrides the
value of the global.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (use_gdb_stub): New procedure.
PR symtab/19914
* dwarf2read.c (open_and_init_dwp_file): Look at backlink if objfile
is separate debug file.
testsuite/
* gdb.dwarf2/dwp-sepdebug.c: New file.
* gdb.dwarf2/dwp-sepdebug.exp: New file.
This test seems to work with both native-gdbserver and
native-extended-gdbserver, so I removed the remote check.
When running with native-gdbserver (a stub-like target), detach makes
gdbserver stop and gdb disconnect. runto_main just spawns a brand new
gdbserver. So it tests the exact same thing twice. It doesn't hurt
though.
With native-extended-gdbserver, the test is probably a bit more useful
(and similar to native). It tests running/detaching twice using the
same gdb/gdbserver instances, since with extended-remote, you can
detach/attach/run all you want, unlike with remote.
gdb/testsuite/ChangeLog:
* gdb.base/detach.exp: Remove is_remote check.
The comment says that we can't use runto_main here becore it doesn't
know how to handle annotation. Instead, the test puts a breakpoint at
main and calls run by hand. Therefore, it can't work with stub targets,
since they can't "run". The check should be then changed to check the
use_gdb_stub variable instead of [is_remote target].
But as an alternative, we can just use runto_main and enable annotations
after, since the "run to main" part is not really part of what we want
to test.
I also removed the "set test..." line that is unused.
gdb/testsuite/ChangeLog:
* gdb.base/annota-input-while-running.exp: Don't check for
[is_remote target]. Enable annotations after running to main.
Remove unused "set test..." line.
This patch adds a test for tracepoints enabling/disabling, which
didn't work properly for fast tracepoints on big endian systems.
gdb/testsuite/ChangeLog:
* gdb.trace/trace-enable-disable.exp: New file.
* gdb.trace/trace-enable-disable.c: New file.
Some fast tracepoints tests make sure that the in-process agent library
is properly loaded, by searching for the library name in "info
sharedlibrary".
Originally, it would search for the full path. Since patch "Make ftrace
tests work with remote targets" [1], the "runtime" location of the IPA,
in the standard output directory, is not the same as the original
location, in the gdbserver build directory. Therefore, the patch
changed the checks:
gdb_test "info sharedlibrary" ".*${libipa}.*" "IPA loaded"
to
gdb_test "info sharedlibrary" ".*[file tail ${libipa}].*" "IPA loaded"
so that only the "libinproctrace.so" part would be searched for.
Antoine (in CC) pointed out that I missed some, so I have to update
them. In the mean time, I noticed that I missed a few test failures:
adding the SONAME to the IPA makes it possible for the test executable
to erroneously pick up libinproctrace.so from /usr/lib if the test
harness failed to put the libinproctrace.so we want to test in the right
place. To mitigate that kind of error in the future, we can use the
return value of gdb_load_shlib (the path of the "runtime" version of the
library) and use that to search in the output of info sharedlibrary.
When testing locally, gdb_load_shlib returns the full normalized path of
the destination library, which the test executable should use e.g.:
/path/to/gdb/testsuite/outputs/gdb.trace/thetest/libinproctrace.so
My testing showed that it was the same path that gdb displayed in info
sharedlibrary. If the test executable picks up another
libinproctrace.so, the test will fail.
When testing remotely, gdb_load_shlib/gdb_remote_download only returns
us "libinproctrace.so", so the situation doesn't really change. If
there is a rogue libinproctrace.so in /usr/lib on the target and we fail
to download ours, it might cover up a test failure. But that situation
is probably still better than the original one, where it wasn't possible
to test remotely using the IPA at all.
[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=6e774b13c3b81ac2599812adf058796948ce7e95
gdb/testsuite/ChangeLog:
* gdb.arch/ftrace-insn-reloc.exp: Save gdb_load_shlib result,
use it in info sharedlibrary test.
* gdb.trace/ftrace-lock.exp: Likewise.
* gdb.trace/ftrace.exp: Likewise.
* gdb.trace/range-stepping.exp: Likewise.
* gdb.trace/trace-break.exp: Likewise.
* gdb.trace/trace-condition.exp: Likewise.
* gdb.trace/trace-mt.exp: Likewise.
This patch makes gdb_load_shlibs return the destination path of the
copied library. To make the procedure implementation and interface more
straightforward, it also changes it so that it accepts a single shared
library path at the time. Therefore, calls that are passed multiple
libraries:
gdb_load_shlibs $lib1 $lib2
must be changed to separate calls:
gdb_load_shlibs $lib1
gdb_load_shlibs $lib2
A subtle impact is the solib-search-path handling. In the former
version, solib-search-path is set using the directory of the first
passed lib (further calls overwrite the value). In the later version,
the directory of the library passed to the last call to gdb_load_shlibs
remnains. I don't think that's a problem in practice, since if we had
tests that needed multiple different paths in solib-search-path, they
wouldn't work in the first place.
Changed in v2:
* Split behavioural and rename changes in two separate patches.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (gdb_load_shlibs): Accept a single argument. Return
result of gdb_remote_download.
* gdb.base/ctxobj.exp: Split gdb_load_shlibs call.
* gdb.base/dso2dso.exp: Likewise.
* gdb.base/global-var-nested-by-dso.exp: Likewise.
* gdb.base/print-file-var.exp: Likewise.
* gdb.base/shlib-call.exp: Likewise.
* gdb.base/shreloc.exp: Likewise.
* gdb.base/solib-overlap.exp: Likewise.
* gdb.base/solib-weak.exp (do_test): Likewise.
* gdb.base/unload.exp: Likewise.
I get a timeout fail in branch-to-self.exp when it is compiled by a
bare-mental target running qemu, which doesn't have signal.
The test should be skipped if gdb,nosignals exists, and that is
what this patch does.
gdb/testsuite:
2016-04-27 Yao Qi <yao.qi@linaro.org>
* gdb.base/branch-to-self.exp: Skip it if gdb,nosignals
exists.
Instead of pre-computing indices into a fortran array re-use
the value_* interfaces to subscript a fortran array.
The benefit of using the new interface is that it takes care of
dynamic types and resolve them when needed.
This fixes issues when printing structures with dynamic arrays from toplevel.
Before:
(gdb) p twov
$1 = ( (( ( 6352320, 0, -66, -1, 267) ( 343476, 1, -15, 1, 0) ( 5, 0, 5, 0, 1) ...
After:
(gdb) p twov
$1 = ( (( ( 1, 1, 1, 1, 1) ( 1, 1, 321, 1, 1) ( 1, 1, 1, 1, 1) ...
2016-04-26 Sanimir Agovic <sanimir.agovic@intel.com>
Keven Boell <keven.boell@intel.com>
Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* f-valprint.c (f77_create_arrayprint_offset_tbl): Remove
function.
(F77_DIM_SIZE, F77_DIM_OFFSET): Remove macro.
(f77_print_array_1): Use value_subscript to subscript a
value array.
(f77_print_array): Remove call to f77_create_arrayprint_offset_tbl.
(f_val_print): Use value_field to construct a field value.
gdb/testsuite/Changelog:
* vla-type.exp: Print structure from toplevel.
Resolve type of an array's element to be printed in case it is dynamic.
Otherwise we don't use the correct boundaries nor the right location.
Before:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(34196784:34196832,34197072:34197120,34197360:34197408)
End Type one :: tone
End Type five
After:
ptype fivearr(1)
type = Type five
Type one
integer(kind=4) :: ivla(2,4,6)
End Type one :: tone
End Type five
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
gdb/Changelog:
* valarith.c (value_address): Resolve dynamic types.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: Add test for static and dynamic arrays
of dynamic types.
* gdb.fortran/vla-type.exp: Add test for static and dynamic arrays
of dynamic types.
Fortran supports dynamic types for which bounds, size and location
can vary during their lifetime. As a result of the dynamic
behaviour, they have to be resolved at every query.
This patch will resolve the type of a structure field when it
is dynamic.
2016-04-26 Bernhard Heckel <bernhard.heckel@intel.com>
2016-04-26 Keven Boell <keven.boell@intel.com>
Before:
(gdb) print threev%ivla(1)
Cannot access memory at address 0x3
(gdb) print threev%ivla(5)
no such vector element
After:
(gdb) print threev%ivla(1)
$9 = 1
(gdb) print threev%ivla(5)
$10 = 42
gdb/Changelog:
* NEWS: Add new supported features for fortran.
* gdbtypes.c (remove_dyn_prop): New.
(resolve_dynamic_struct): Keep type length for fortran structs.
* gdbtypes.h: Forward declaration of new function.
* value.c (value_address): Return dynamic resolved location of a value.
(set_value_component_location): Adjust the value address
for single value prints.
(value_primitive_field): Support value types with a dynamic location.
(set_internalvar): Remove dynamic location property of
internal variables.
gdb/testsuite/Changelog:
* gdb.fortran/vla-type.f90: New file.
* gdb.fortran/vla-type.exp: New file.
I am seeing some test fails in gdb.trace/unavailable.exp on aarch64-linux,
like this,
print derived_whole^M
$43 = (Derived) {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object on: print derived_whole
print derived_whole^M
$47 = {<Middle> = {<Base> = {x = 2}, _vptr.Middle = 0x401860 <VTT for Derived>, y = 3}, _vptr.Derived = 0x401848 <vtable for Derived+32>, z = 4}^M
(gdb) FAIL: gdb.trace/unavailable.exp: collect globals: print object off: print derived_whole
these fails are also found by recent x86_64-linux buildbot,
https://sourceware.org/ml/gdb-testers/2016-q2/msg00622.html
The fix is exactly the same as this one
http://www.sourceware.org/ml/gdb-patches/2015-10/msg00252.html (the
extra "VTT" after hex), in which we match extra things after $hex.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/unavailable.exp (gdb_collect_globals_test_1): Match
more after $hex.
Hi,
I am seeing the fail below on aarch64-linux with gcc 4.9.2,
break main
Breakpoint 1 at 0x4006e8: file binutils-gdb/gdb/testsuite/gdb.base/annota1.c, line 14.^M
(gdb) FAIL: gdb.base/annota1.exp: breakpoint main
the test expects the breakpoint is set on line 15. Let us look at
the main function,
12 int
13 main (void)
14 {
15 int my_array[3] = { 1, 2, 3 }; /* break main */
16
17 value = 7;
18
19 #ifdef SIGUSR1
20 signal (SIGUSR1, handle_USR1);
21 #endif
(gdb) disassemble main
Dump of assembler code for function main:
0x00000000004006e0 <+0>: stp x29, x30, [sp,#-48]!
0x00000000004006e4 <+4>: mov x29, sp
0x00000000004006e8 <+8>: adrp x0, 0x411000 <signal@got.plt>
0x00000000004006ec <+12>: add x0, x0, #0x40
the breakpoint is set on the right address after skipping prologue, but
0x00000000004006e8 is mapped to the line 14, as shown below,
(gdb) maintenance info line-table
objfile: /home/yao.qi/source/build-aarch64/gdb/testsuite/outputs/gdb.base/annota1/annota1 ((struct objfile *) 0x2b0e1850)
compunit_symtab: ((struct compunit_symtab *) 0x2b0ded50)
symtab: /home/yao.qi/source/binutils-gdb/gdb/testsuite/gdb.base/annota1.c ((struct symtab *) 0x2b0dedd0)
linetable: ((struct linetable *) 0x2b12c8b0):
INDEX LINE ADDRESS
0 7 0x00000000004006d0
1 8 0x00000000004006d8
2 14 0x00000000004006e0
3 14 0x00000000004006e8
4 15 0x00000000004006fc
so GDB does nothing wrong. Program hits breakpoint on either line 14
or line 15 is right to me. With anther gcc (4.9.3), the line-table looks
correct, and no test fail. Instead of setting breakpoint on main and
assuming the line is what we get from the source, we can set breakpoint
on that line. On the other hand, the test prints the values of the
array and check, so we need to set breakpoint on the line setting the
values of array and "next", rather than setting the breakpoint on main.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.base/annota1.exp: Set breakpoint on line $main_line.
* gdb.base/annota3.exp: Likewise.
I see the following test fail in arm-linux with -marm and -fomit-frame-pointer,
step
callee () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:27
27 } /* RETURN FROM CALLEE */
(gdb) step
main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.reverse/step-reverse.c:58
58 callee(); /* STEP INTO THIS CALL */
(gdb) FAIL: gdb.reverse/step-precsave.exp: reverse step into fn call
As we can see, the "step" has already stepped into the function callee,
but in the last line. The second "step" attempts to step to function
body, but it goes out of callee, which isn't expected.
The program is compiled with -marm and -fomit-frame-pointer, the
function callee is prologue-less, because nothing needs to be saved
on stack,
(gdb) disassemble callee
Dump of assembler code for function callee:
0x00010680 <+0>: movw r3, #2364 ; 0x93c
0x00010684 <+4>: movt r3, #2
0x00010688 <+8>: ldr r3, [r3]
0x0001068c <+12>: add r2, r3, #1
0x00010690 <+16>: movw r3, #2364 ; 0x93c
0x00010694 <+20>: movt r3, #2
0x00010698 <+24>: str r2, [r3]
0x0001069c <+28>: mov r3, #0
0x000106a0 <+32>: mov r0, r3
0x000106a4 <+36>: bx lr
program stops at the 0x106a0 (passed the epilogue) after the first
"step". When second "step" is executed, the stepping range is
[0x10680-0x106a0], which starts from the first instruction of function
callee (because it doesn't have prologue).
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [LWP 2461] at 0x1069c^M
infrun: prepare_to_wait^M
infrun: target_wait (-1.0.0, status) =^M
infrun: 2461.2461.0 [LWP 2461],^M
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP^M
infrun: TARGET_WAITKIND_STOPPED^M
infrun: stop_pc = 0x10698^M
infrun: stepping inside range [0x10680-0x106a0]
When program goes out of the range, it stops at the caller of callee,
and test fails. IOW, if function callee has prologue, the stepping
range won't start from the first instruction of the function, and
program stops at the prologue and test passes.
IMO, GDB does nothing wrong, but test shouldn't expect the program
stops in callee after the second "step". I decide to fix test rather
than GDB. In this patch, I change to test to do one "step", and check
the program is still in callee, then, do multiple "step" until program
goes out of the callee.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.reverse/step-precsave.exp: Do one step and test program
stops in "callee" and do multiple steps until program goes out
of "callee".
* gdb.reverse/step-reverse.exp: Likewise.
GDBserver doesn't deliver signal when stepping over a breakpoint even
hardware single step is used. When GDBserver started to step over
(thread creation) breakpoint for mutlit-threaded debugging in 2002 [1],
GDBserver behaves this way.
This behavior gets trouble on conditional breakpoints on branch to
self instruction like this,
0x00000000004005b6 <+29>: jmp 0x4005b6 <main+29>
and I set breakpoint
$(gdb) break branch-to-self.c:43 if counter > 3
and the variable counter will be set to 5 in SIGALRM signal handler.
Since GDBserver keeps stepping over breakpoint, the SIGALRM can never
be dequeued and delivered to the inferior, so the program can't stop.
The test can be found in gdb.base/branch-to-self.exp.
GDBserver didn't deliver signal when stepping over a breakpoint because
a tracepoint is collected twice if GDBserver does so in the following
scenario, which can be reproduced by gdb.trace/signal.exp.
- program stops at tracepoint, and tracepoint is collected,
- gdbserver starts a step-over,
- a signal arrives, step-over is canceled, and signal should be passed,
- gdbserver starts a new step-over again, pass the signal as well,
- program stops at the entry of signal handler, step-over finished,
- gdbserver proceeds,
- program returns from the signal handler, again to the tracepoint,
and thus is collected again.
The spurious collection isn't that harmful, IMO, so it should be OK
to let GDBserver deliver signal when stepping over a breakpoint.
gdb/gdbserver:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* linux-low.c (lwp_signal_can_be_delivered): Don't deliver
signal when stepping over breakpoint with software single
step.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.exp: Also pass if
$tracepoint_hits($i) > $iterations.
This is to test whether GDBserver deliver signal to the inferior while
doing the step over. Nowadays, GDBserver doesn't deliver signal, so
there won't be spurious collection, however, if GDBserver does deliver
signal, there might be spurious collection.
gdb/testsuite:
2016-04-22 Yao Qi <yao.qi@linaro.org>
* gdb.trace/signal.c: New file.
* gdb.trace/signal.exp: New file.
Andreas Arnez
Simon Marchi
Kevin Buettner
Catherine Moore
Pedro Alves
Tom Tromey
Manish Goregaokar
Luis Machado
Sandra Loosemore
Jan Kratochvil
Maciej W. Rozycki
Simon Marchi
Yao Qi
Markus Metzger
Doug Evans
Antoine Tremblay
Peter Bergner
Anton Kolesov
Sergio Durigan Junior
Jon Beniston
Ulrich Weigand
Carl E. Love
Carl Love
Tim Wiederhake
Gabriel Krisman Bertazi
Don Breazeal
Walfred Tedeschi
Pierre-Marie de Rodat
David Taylor
Sanjoy Das
Yan-Ting Lin
Andrew Burgess
Bernhard Heckel
Toshihito Kikuchi
Martin Galvan
Francis Ricci
Keven Boell
Doug Evans