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>
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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
on CentOS-7.2 I get
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit.exp ...
FAIL: gdb.base/jit.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 1
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: detach (the program is no longer running)
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: attach
FAIL: gdb.base/jit.exp: attach: one_jit_test-2: break here 2: set var wait_for_gdb = 0
FAIL: gdb.base/jit.exp: PIE: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
Running /home/jkratoch/redhat/gdb-test-reg/gdb/testsuite/gdb.base/jit-so.exp ...
FAIL: gdb.base/jit-so.exp: one_jit_test-1: continue to breakpoint: break here 2 (the program exited)
FAIL: gdb.base/jit-so.exp: one_jit_test-2: continue to breakpoint: break here 2 (the program exited)
since:
85af34ee0211eedf8d30a5c44dfc59dddf8b512a is the first bad commit
commit 85af34ee0211eedf8d30a5c44dfc59dddf8b512a
Author: Pedro Alves <palves@redhat.com>
Date: Thu Mar 31 19:28:47 2016 +0100
Add regression test for PR gdb/19858 (JIT code registration on attach)
The compiled code's .debug_line is wrong (for the simplistic approach of GDB
to put a breakpoint on the first address belonging to that source line) and so
GDB misses the breakpoint at the last line:
WAIT_FOR_GDB; return 0; /* gdb break here 2 */
Most of the patch is just about reindentation, no changes there.
gdb/testsuite/ChangeLog
2016-04-08 Jan Kratochvil <jan.kratochvil@redhat.com>
Fix compatibility with gcc-4.8.5-4.el7.x86_64.
* gdb.base/jit-main.c: Use exit after usage.
$ GDBHISTFILE=/tmp/gdbhistfile runtest gdb.base/gdbhistsize-history.exp gdb.base/gdbinit-history.exp
Running ./gdb.base/gdbinit-history.exp ...
FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=1000: show commands
FAIL: gdb.base/gdbinit-history.exp: home=gdbinit-history/unlimited gdbhistsize=foo: show commands
Running ./gdb.base/gdbhistsize-history.exp ...
FAIL: gdb.base/gdbhistsize-history.exp: histsize=: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=20: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize= 20 : show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=not_an_integer: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=10zab: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=-5ab: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=99999999999999999999999999999999999: show commands
FAIL: gdb.base/gdbhistsize-history.exp: histsize=50: show commands
This happens for my setup due to my:
$ grep GDB ~/.bashrc
export GDBHISTFILE="$HOME/.gdb_history"
gdb/testsuite/ChangeLog
2016-04-07 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.base/gdbhistsize-history.exp: Save and unset GDBHISTFILE and
GDBHISTSIZE prior to the tests.
* gdb.base/gdbinit-history.exp: Likewise.
This patch removes gdb_download in favor of gdb_remote_download, since
they are very close in functionality. Also, in preparation for the
following patch about shared library handling during tests, it improves
gdb_remote_download so that it uses standard_output_file for any
destination board that is local, not only host.
If the destination board is remote, gdb_remote_download will use the
standard remote_download from DejaGnu, resulting in the file being
transferred on the remote system.
If the destination is local, gdb_remote_download will copy the file to
the standard test directory (found using standard_output_file). Tcl's
file copy seems to handle gracefully cases where the source file is the
same as the destination, so I don't think it's necessary to check for
that case ourselves, as a previous version of the patch did.
I'd prefer to keep the name gdb_download instead of gdb_remote_download,
since I don't like the fact that gdb_remote_download implies that the
destination is remote, when it's not always the case. However,
gdb_remote_download is used at many more places than gdb_download, so
it's easier to reuse that. Also, since it's a wrapper around DejaGnu's
remote_download, it might be better to keep that name. I don't know.
I ran the testsuite native, with native-gdbserver and with a
remote gdbserver, and didn't see any related failure.
gdb/testsuite/ChangeLog:
* gdb.base/jit-so.exp: Use gdb_remote_download instead of
gdb_download. Use it even if the target is not remote.
* gdb.base/jit.exp (compile_jit_test): Likewise.
* lib/gdb.exp (gdb_remote_download): Copy files to the standard
output directory if the destination board is local, otherwise use
the standard remote_download from DejaGnu.
(gdb_download): Remove.
(gdb_load_shlibs): Use gdb_remote_download instead of
gdb_download.
* lib/gdbserver-support.exp (gdbserver_download_current_prog):
Use gdb_remote_download instead of gdb_download. Use it even if
the target is not remote.
* lib/mi-support.exp (mi_load_shlibs): Use gdb_remote_download
instead of gdb_download.
This patch adds support for TYPE_CODE_ENUM values to be supplied
as right-hand side operand of the BINOP_REPEAT (@) operator. The
following should now work:
enum {
sz = 17
};
int
main ()
{
int arr[sz + 1] = { 0 };
return 0; /* line 9 here */
}
(gdb) b 9
(gdb) r
(gdb) p arr@sz
$1 = {0 <repeats 17 times>}
(gdb)
A couple of tests is also included in this patch to demonstrate that it is
working as intended.
gdb/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* eval.c (evaluate_subexp_standard): Allow TYPE_CODE_ENUM to be
the type of BINOP_REPEAT's second operand.
gdb/testsuite/Changelog:
2016-04-01 Artemiy Volkov <artemiyv@acm.org>
PR gdb/19820
* gdb.base/printcmds.exp: Add artificial arrays tests.
This test would fail without the previous gdb/jit.c fix:
(gdb) attach 23031
Attaching to program: .../build/gdb/testsuite/outputs/gdb.base/jit/jit-main, process 23031
[...]
207 WAIT_FOR_GDB; i = 0; /* gdb break here 1 */
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: attach
set var wait_for_gdb = 0
(gdb) PASS: gdb.base/jit.exp: attach: one_jit_test-2: set var wait_for_gdb = 0
info function ^jit_function
All functions matching regular expression "^jit_function":
(gdb) FAIL: gdb.base/jit.exp: attach: one_jit_test-2: info function ^jit_function
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit-main.c: Include unistd.h.
(ATTACH): Define to 0 if not already defined.
(wait_for_gdb, mypid): New globals.
(WAIT_FOR_GDB): New macro.
(MAIN): Set an alarm. Store the process's pid. Wait for GDB at
some breakpoint locations.
* gdb.base/jit.exp (clean_reattach, continue_to_test_location):
New procedures.
(one_jit_test): Add REATTACH parameter, and handle it. Use
continue_to_test_location.
(top level): Test attach, and adjusts calls to one_jit_test.
This testcase compiles the same program and library differently
multiple times using the same file names. Make them unique, to make
it easier to debug test problems.
gdb/testsuite/ChangeLog:
2016-03-31 Pedro Alves <palves@redhat.com>
PR gdb/19858
* gdb.base/jit.exp (compile_jit_test): Add intro comment. Add
BINSUFFIX parameter, and handle it.
(top level): Adjust calls compile_jit_test.
When adding the $_as_string convenience function, I missed a new test
failure in default.exp. The tests lists the convenience functions, so
$_as_string should be added to the expected list.
Fixes:
+FAIL: gdb.base/default.exp: show convenience ($_caller_is = <internal function _caller_is> not found)
gdb/testsuite/ChangeLog:
* gdb.base/default.exp: Add $_as_string to the list of expected
convenience functions.
Add a new command 'maint info line-table' to display the contents of
GDB's internal line table structure. Useful when trying to understand
problems (within gdb) relating to line tables.
gdb/ChangeLog:
* symmisc.c (maintenance_info_line_tables): New function.
(maintenance_print_one_line_table): New function.
(_initialize_symmisc): Register 'maint info line-table' command.
* NEWS: Mention new command.
gdb/doc/ChangeLog:
* gdb.texinfo (Symbols): Document new 'maint info line-table'
command.
gdb/testsuite/ChangeLog:
* gdb.base/maint.exp: New tests for 'maint info line-table'.
I happened to break this locally and the testsuite didn't notice it.
Add some tests.
gdb/ChangeLog:
2016-03-09 Pedro Alves <palves@redhat.com>
* gdb.base/command-line-input.exp: New file.
This patch adds a new test for stepping over clone syscall.
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/step-over-syscall.exp (step_over_syscall): Kfail.
Invoke step_over_syscall "clone" and break_cond_on_syscall
"clone".
* gdb.base/step-over-clone.c: New file.
disp-step-syscall.exp is extended for stepping over syscall instruction
in different cases, with or without displaced stepping, and stepping
over by GDBserver.
This patch rename disp-step-syscall.exp to step-over-syscall.exp to
reflect this.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-fork.c: Rename to ...
* gdb.base/step-over-fork.c: ... it. New file.
* gdb.base/disp-step-vfork.c: Rename to ...
* gdb.base/step-over-vfork.c: ... it. New file.
* gdb.base/disp-step-syscall.exp: Rename to ...
* gdb.base/step-over-syscall.exp: ... it. New file.
(disp_step_cross_syscall): Rename to ...
(step_over_syscall): ... it.
We can also extend disp-step-syscall.exp to test GDBserver step over
breakpoint on syscall instruction. That is, we set a breakpoint
with a false condition on syscall instruction, so that GDBserver will
step over it.
This test triggers a GDBserver internal error, which can be fixed by
this series.
(gdb) PASS: gdb.base/disp-step-syscall.exp: fork: break cond on target: break on syscall insns
continue^M
Continuing.^M
Remote connection closed^M
(gdb) FAIL: gdb.base/disp-step-syscall.exp: fork: break cond on target: continue to fork again
In GDBserver, there is an internal error,
/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:1922: A problem internal to GDBserver has been detected.
unsuspend LWP 25554, suspended=-1
the simplified reproducer is like,
$ ./gdb ./testsuite/outputs/gdb.base/disp-step-syscall/disp-step-fork
(gdb) b main
(gdb) c
(gdb) disassemble fork // in order to find the address of insn 'syscall'
....
0x00007ffff7ad6023 <+179>: syscall
(gdb) b *0x00007ffff7ad6023 if main == 0
(gdb) c
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (break_cond_on_syscall): New.
If target supports condition evaluation on target, invoke
break_cond_on_syscall for fork and vfork.
disp-step-syscall.exp was added to test displaced stepping over syscall
instructions, in which we set breakpoint on syscall instruction, and
step over it. In fact, we can extend the test to non-displaced-stepping
case. This patch wraps the test with displaced stepping on and off.
Note that the indentation and format isn't adjusted here to make this
patch easy to read. The following patch will fix the format separately.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp: Don't invoke
support_displaced_stepping.
(disp_step_cross_syscall): Test with displaced stepping off and
on if supported.
This patch moves some code out of disp_step_cross_syscall to a new proc
check_pc_after_cross_syscall and setup. Procedure setup is to start a
fresh GDB and compute the syscall instruction address.
gdb/testsuite:
2016-03-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (check_pc_after_cross_syscall): New
proc.
(setup): New proc.
(disp_step_cross_syscall): Move code to check_pc_after_cross_syscall
and setup.
This patch removes gdb.base/branches.c which was added by the following
commit, but it is not used at all.
commit ea8122af14
Author: John Metzler <jmetzler@cygnus>
Date: Thu Apr 16 17:56:11 1998 +0000
Thu Apr 16 10:52:34 1998 John Metzler <jmetzler@cygnus.com>
* gdb.base/branches.c: Code with lots of loops and
subroutines. Used to test gdbs ability to single step through PC
changes, especially to test mips-tdep.c:mips_next_pc
gdb/testsuite:
2016-02-25 Yao Qi <yao.qi@linaro.org>
* gdb.base/branches.c: Remove.
This commit fixes an error in exec_file_locate_attach where
the main executable could be loaded from outside the sysroot
if a nonempty, non-"target:" sysroot was set but the discovered
executable filename did not exist in that sysroot and did exist
on the main filesystem.
gdb/ChangeLog:
* exec.c (exec_file_locate_attach): Do not attempt to
locate main executable locally if not found in sysroot.
gdb/testsuite/ChangeLog:
* gdb.base/attach-pie-noexec.exp: Do not expect an error
message on attach.
gdb/ChangeLog:
Extend "skip" command to support -file, -gfile, -function, -rfunction.
* NEWS: Document new features.
* skip.c: #include "fnmatch.h", "gdb_regex.h".
(skiplist_entry) <file>: Renamed from filename.
<function>: Renamed from function_name.
<file_is_glob, function_is_regexp>: New members.
<compiled_function_regexp, compiled_function_regexp_is_valid>:
New members.
(make_skip_entry): New function.
(free_skiplist_entry, free_skiplist_entry_cleanup): New functions.
(make_free_skiplist_entry_cleanup): New function.
(skip_file_command): Update.
(skip_function, skip_function_command): Update.
(compile_skip_regexp): New functions.
(skip_command): Add support for new options.
(skip_info): Update.
(skip_file_p, skip_gfile_p): New functions.
(skip_function_p, skip_rfunction_p): New functions.
(function_name_is_marked_for_skip): Update and simplify.
(_initialize_step_skip): Update.
* symtab.c: #include "fnmatch.h".
(compare_glob_filenames_for_search): New function.
* symtab.h (compare_glob_filenames_for_search): Declare.
* utils.c (count_path_elements): New function.
(strip_leading_path_elements): New function.
* utils.h (count_path_elements): Declare.
(strip_leading_path_elements): Declare.
gdb/doc/ChangeLog:
* gdb.texinfo (Skipping Over Functions and Files): Document new
options to "skip" command. Update docs of output of "info skip".
gdb/testsuite/ChangeLog:
* gdb.base/skip.c (test_skip): New function.
(end_test_skip_file_and_function): New function.
(test_skip_file_and_function): New function.
* gdb.base/skip1.c (test_skip): New function.
(skip1_test_skip_file_and_function): New function.
* gdb.base/skip.exp: Add tests for new skip options.
* gdb.base/skip-solib.exp: Update expected output.
* gdb.perf/skip-command.cc: New file.
* gdb.perf/skip-command.exp: New file.
* gdb.perf/skip-command.py: New file.
This patch series add fork support in target remote,
[PATCH v2 0/3] Target remote mode fork and exec support
https://sourceware.org/ml/gdb-patches/2015-12/msg00144.html
so GDB can be informed about the child, and adjust child correctly in
displaced stepping. The PR server/13796 was fixed by this patch
series actually. Test results on buildbot show this KFAIL->KPASS
change https://sourceware.org/ml/gdb-testers/2015-q4/msg10128.html
gdb/testsuite:
2016-02-18 Yao Qi <yao.qi@linaro.org>
* gdb.base/disp-step-syscall.exp (disp_step_cross_syscall):
Don't call setup_kfail.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full.exp: Use standard_output_file to
define object file path.
* gdb.btrace/gcore.exp: Use standard_output_file to define core
file path.
* lib/opencl.exp (gdb_compile_opencl_hostapp): Use
standard_output_file to define binfile.
One of the last checks update_breakpoints_after_exec does while looping
over the list of breakpoints is check that the breakpoint has a valid
location spec. It uses event_location_empty_p to check if the location spec
is "empty", and if it is, the breakpoint is deleted.
momentary_breakpoint types rely on setting the breakpoint structure's
location spec to NULL, thereby causing an update to delete the breakpoint.
However, event_location_empty_p assumed that locations were never NULL.
As a result, GDB would crash dereferencing a NULL pointer whenever
update_breakpoints_after_exec would encounter a momentary_breakpoint.
This patch creates a new wrapper/helper function which tests that the given
breakpoint's location spec is non-NULL and if it is not "empty"
or "unspecified."
gdb/ChangeLog
PR breakpoints/19546
* breakpoint.c (breakpoint_event_location_empty_p): New function.
(update_breakpoints_after_exec, bkpt_re_set): Use this new function
instead of event_location_empty_p.
gdb/testsuite/ChangeLog
PR breakpoints/19546
* gdb.base/infcall-exec.c: New file.
* gdb.base/infcall-exec2.c: New file.
* gdb.base/infcall-exec.exp: New file.
PR19548 shows that we still have problems related to 13fd3ff34329:
[PR17431: following execs with "breakpoint always-inserted on"]
https://sourceware.org/ml/gdb-patches/2014-09/msg00733.html
The problem this time is that we currently update the global location
list and try to insert breakpoint locations after re-setting _each_
breakpoint in turn.
Say:
- We have _more_ than one breakpoint set. Let's assume 2.
- There's a breakpoint with a pre-exec address that ends up being an
unmapped address after the exec.
- That breakpoint is NOT the first in the breakpoint list.
Then when handling an exec, and we re-set the first breakpoint in the
breakpoint list, we mistakently try to install the old pre-exec /
un-re-set locations of the other breakpoint, which fails:
(gdb) continue
Continuing.
process 28295 is executing new program: (...)/execl-update-breakpoints2
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x1000764
Breakpoint 1, main (argc=1, argv=0x7fffffffd368) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/execl-update-breakpoints.c:34
34 len = strlen (argv[0]);
(gdb)
Fix this by deferring the global location list update till after all
breakpoints are re-set.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* breakpoint.c (create_overlay_event_breakpoint): Don't update
global location list here.
(create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, create_jit_event_breakpoint)
(update_breakpoint_locations):
(breakpoint_re_set): Update global location list after all
breakpoints are re-set.
gdb/testsuite/ChangeLog:
2016-02-09 Pedro Alves <palves@redhat.com>
PR breakpoints/19548
* gdb.base/execl-update-breakpoints.c (some_function): New
function.
(main): Call it.
* gdb.base/execl-update-breakpoints.exp: Add a second breakpoint.
Tighten expected GDB output.
When running tests in parallel, each test puts its generated files in a
different directory, under "outputs". I think it would be nice if it
was always the case, as it would isolate the test cases a bit more. An
artifact created by a test wouldn't get overwritten by another test.
Also, it makes it easier to clean up. A lot of executables are left all
over the place because their names do not appear in gdb.*/Makefile. If
everything is in "outputs", then we just have to delete that directory
(which we already do).
At the same time it makes the gdb.foo directories and their Makefiles
useless in the build directory, since they are pretty much only used for
cleaning.
What do you think?
gdb/testsuite/ChangeLog:
* Makefile.in (ALL_SUBDIRS): Remove.
(clean mostlyclean): Do not recurse in ALL_SUBDIRS.
(distclean maintainer-clean realclean): Likewise.
* configure.ac (AC_OUTPUT): Remove gdb.*/Makefile.
* configure: Regenerate.
* gdb.ada/Makefile.in: Delete.
* gdb.arch/Makefile.in: Likewise.
* gdb.asm/Makefile.in: Likewise.
* gdb.base/Makefile.in: Likewise.
* gdb.btrace/Makefile.in: Likewise.
* gdb.cell/Makefile.in: Likewise.
* gdb.compile/Makefile.in: Likewise.
* gdb.cp/Makefile.in: Likewise.
* gdb.disasm/Makefile.in: Likewise.
* gdb.dlang/Makefile.in: Likewise.
* gdb.dwarf2/Makefile.in: Likewise.
* gdb.fortran/Makefile.in: Likewise.
* gdb.gdb/Makefile.in: Likewise.
* gdb.go/Makefile.in: Likewise.
* gdb.guile/Makefile.in: Likewise.
* gdb.java/Makefile.in: Likewise.
* gdb.linespec/Makefile.in: Likewise.
* gdb.mi/Makefile.in: Likewise.
* gdb.modula2/Makefile.in: Likewise.
* gdb.multi/Makefile.in: Likewise.
* gdb.objc/Makefile.in: Likewise.
* gdb.opencl/Makefile.in: Likewise.
* gdb.opt/Makefile.in: Likewise.
* gdb.pascal/Makefile.in: Likewise.
* gdb.perf/Makefile.in: Likewise.
* gdb.python/Makefile.in: Likewise.
* gdb.reverse/Makefile.in: Likewise.
* gdb.server/Makefile.in: Likewise.
* gdb.stabs/Makefile.in: Likewise.
* gdb.threads/Makefile.in: Likewise.
* gdb.trace/Makefile.in: Likewise.
* gdb.xml/Makefile.in: Likewise.
* lib/gdb.exp (make_gdb_parallel_path): Add check for
GDB_PARALLEL.
(standard_output_file): Remove check for GDB_PARALLEL, always
return path in outputs/$subdir/$testname.
BASEDIR was added by https://sourceware.org/ml/gdb-patches/2013-10/msg00587.html
in order to handle the different directory layout in serial testing
and parallel testing. BASEDIR is "gdb.base" in serial testing and is
"outputs/gdb.base/TESTNAME" in parallel testing. However, it doesn't
work if the GDBserver is in remote target, like this,
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost foll-vfork.exp foll-exec.exp'
FAIL: gdb.base/foll-exec.exp: continue to first exec catchpoint (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork and exec child follow, to main bp: continue to bp (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: finish (the program exited)
FAIL: gdb.base/foll-vfork.exp: exec: vfork relations in info inferiors: continue to bp (the program exited)
these tests fail because the executable can't be found. With target
board native-gdbserver, the program is spawned this way,
spawn ../gdbserver/gdbserver --once :2347 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR is correct. However, with target board
remote-gdbserver-on-localhost, the program is spawned
spawn /usr/bin/ssh -l yao localhost /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/../gdbserver/gdbserver --once :2346 /scratch/yao/gdb/build-git/x86_64/gdb/testsuite/gdb.base/foll-vfork
so BASEDIR (either "gdb.base" or "outputs/gdb.base/TESTNAME") makes no
sense.
I had a fix that pass absolute directory to BASEDIR, but it assumes
that directory structure is the same on build and target, and it
doesn't work in remote host case. The current fix in this patch is
to get the directory from argv[0]. In any case, the program to be
exec'ed is at the same directory with the main program.
Note that these tests do "next N" to let program stop at the desired
line, but it is fragile, because GDB for different targets may skip
function prologue slightly differently, so I replace some of them by
"tbreak on LINE NUMBER and continue".
gdb/testsuite:
2016-02-04 Yao Qi <yao.qi@linaro.org>
* gdb.base/foll-exec-mode.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-exec-mode.exp: Don't pass -DBASEDIR in
compilation.
* gdb.base/foll-exec.c: Include limits.h.
(main): Add parameters argc and argv.
Get directory from argv[0].
* gdb.base/foll-exec.exp: Don't pass -DBASEDIR in compilation.
Adjust tests on the number of lines as source code changed.
* gdb.base/foll-vfork-exit.c: Include limits.h.
(main): Add one line of statement before vfork.
* gdb.base/foll-vfork.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.base/foll-vfork.exp: Don't pass -DBASEDIR in compilation.
(setup_gdb): Set tbreak to skip some source lines.
* gdb.multi/bkpt-multi-exec.c: Include limits.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/bkpt-multi-exec.exp: Don't pass -DBASEDIR in
compilation.
* gdb.multi/multi-arch-exec.c: Include limits.h and string.h.
(main): Add parameters argc and argv. Get directory from
argv[0].
* gdb.multi/multi-arch-exec.exp: Don't pass -DBASEDIR in
compilation.
For languages with dynamic types, an incorrect program, or uninitialised
variables within a program, could result in an incorrect, overly large
type being associated with a value. Currently, attempting to print such
a variable will result in gdb trying to allocate an overly large buffer.
If this large memory allocation fails then the result can be gdb either
terminating, or (due to memory contention) becoming unresponsive for the
user.
A new user visible variable in gdb helps guard against such problems,
two new commands are available:
set max-value-size
show max-value-size
The 'max-value-size' is the maximum size of memory in bytes that gdb
will allocate for the contents of a value. Any attempt to allocate a
value with a size greater than this will result in an error. The
initial default for this limit is set at 64k, this is based on a similar
limit that exists within the ada specific code.
It is possible for the user to set max-value-size to unlimited, in which
case the old behaviour is restored.
gdb/ChangeLog:
* value.c (max_value_size): New variable.
(MIN_VALUE_FOR_MAX_VALUE_SIZE): New define.
(show_max_value_size): New function.
(check_type_length_before_alloc): New function.
(allocate_value_contents): Call check_type_length_before_alloc.
(set_value_enclosing_type): Likewise.
(_initialize_values): Add set/show handler for max-value-size.
* NEWS: Mention new set/show command.
gdb/doc/ChangeLog:
* gdb.texinfo (Value Sizes): New section.
(Data): Add the 'Value Sizes' node to the menu.
gdb/testsuite/ChangeLog:
* gdb.base/max-value-size.c: New file.
* gdb.base/max-value-size.exp: New file.
* gdb.base/huge.exp: Disable max-value-size for this test.
If you have "set follow-fork child" set, then if you do "info threads"
right after a fork, and before the child reports any other event to
GDB core, you'll see:
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 0x7ffff7fc1740 (LWP 31875) "fork-plus-threa" (running)
2.1 process 31879 "fork-plus-threa" Selected thread is running.
(gdb)
The "Selected thread is running." bit is a bogus error. That was GDB
trying to fetch the current frame of thread 2.1, because the external
runnning state is "stopped", and then throwing an error because the
thread is actually running.
This actually affects all-stop + schedule-multiple as well.
The problem here is that on a fork event, GDB doesn't update the
external parent/child running states.
New comprehensive test included. The "kill inferior 1" / "kill
inferior 2" bits also trip on PR gdb/19494 (hang killing unfollowed
fork children), which was fixed by the previous patch.
gdb/ChangeLog:
2016-01-25 Pedro Alves <palves@redhat.com>
PR threads/19461
* infrun.c (handle_inferior_event_1) <fork/vfork>: Update
parent/child running states.
gdb/testsuite/ChangeLog:
2016-01-25 Pedro Alves <palves@redhat.com>
PR threads/19461
* gdb.base/fork-running-state.c: New file.
* gdb.base/fork-running-state.exp: New file.
linux_nat_kill relies on get_last_target_status to determine whether
the current inferior is stopped at a unfollowed fork/vfork event.
This is bad because many things can happen ever since we caught the
fork/vfork event... This commit rewrites that code to instead walk
the thread list looking for unfollowed fork events, similarly to what
was done for remote.c.
New test included. The main idea of the test is make sure that when
the program stops for a fork catchpoint, and the user kills the
parent, gdb also kills the unfollowed fork child. Since the child
hasn't been added as an inferior at that point, we need some other
portable way to detect that the child is gone. The test uses a pipe
for that. The program forks twice, so you have grandparent, child and
grandchild. The grandchild inherits the write side of the pipe. The
grandparent hangs reading from the pipe, since nothing ever writes to
it. If, when GDB kills the child, it also kills the grandchild, then
the grandparent's pipe read returns 0/EOF and the test passes.
Otherwise, if GDB doesn't kill the grandchild, then the pipe read
never returns and the test times out, like:
FAIL: gdb.base/catch-fork-kill.exp: fork-kind=fork: exit-kind=kill: fork: kill parent (timeout)
FAIL: gdb.base/catch-fork-kill.exp: fork-kind=vfork: exit-kind=kill: vfork: kill parent (timeout)
No regressions on x86_64 Fedora 20. New test passes with gdbserver as
well.
gdb/ChangeLog:
2016-01-25 Pedro Alves <palves@redhat.com>
PR gdb/19494
* linux-nat.c (kill_one_lwp): New, factored out from ...
(kill_callback): ... this.
(kill_wait_callback): New, factored out from ...
(kill_wait_one_lwp): ... this.
(kill_unfollowed_fork_children): New function.
(linux_nat_kill): Use it.
gdb/testsuite/ChangeLog:
2016-01-25 Pedro Alves <palves@redhat.com>
PR gdb/19494
* gdb.base/catch-fork-kill.c: New file.
* gdb.base/catch-fork-kill.exp: New file.
This patch unbuffer the output of the program so that the test harness
can count the number of "done" from output correctly.
gdb/testsuite:
2016-01-22 Yao Qi <yao.qi@linaro.org>
PR testsuite/19491
* gdb.base/multi-forks.c: Include
../lib/unbuffer_output.c
(main): Call gdb_unbuffer_output.
A relatively recent patch support for explicit locations, and part
of that patch cleaned up the way we parse breakpoint locations.
Unfortunatly, a small regression crept in for "*<EXPR>" breakpoint
locations. In particular, on PIE programs, one can see the issue by
doing the following, with any program:
(gdb) b *main
Breakpoint 1 at 0x51a: file hello.c, line 3.
(gdb) run
Starting program: /[...]/hello
Error in re-setting breakpoint 1: Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x51a
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x51a
Just for the record, this regression was introduced by:
commit a06efdd6ef
Date: Tue Aug 11 17:09:35 2015 -0700
Subject: Explicit locations: introduce address locations
What happens is that the patch makes the implicit assumption that
the address computed the first time is static, as if it was designed
to only support litteral expressions (Eg. "*0x1234"). This allows
the shortcut of not re-computing the breakpoint location's address
when re-setting breakpoints.
However, this does not work in general, as demonstrated in the example
above.
This patch plugs that hole simply by saving the original expression
used to compute the address as part of the address location, so as
to then re-evaluate that expression during breakpoint re-set.
gdb/ChangeLog:
* location.h (new_address_location): Add new parameters
"addr_string" and "addr_string_len".
(get_address_string_location): Add declaration.
* location.c (new_address_location): Add new parameters
"addr_string" and "addr_string_len". If not NULL, store
a copy of the addr_string in the new location as well.
(get_address_string_location): New function.
(string_to_event_location): Update call to new_address_location.
* linespec.c (event_location_to_sals) <ADDRESS_LOCATION>:
Save the event location in the parser's state before
passing it to convert_address_location_to_sals.
* breakpoint.c (create_thread_event_breakpoint): Update call
to new_address_location.
(init_breakpoint_sal): Get the event location's string, if any,
and use it to update call to new_address_location.
* python/py-finishbreakpoint.c (bpfinishpy_init):
Update call to new_address_location.
* spu-tdep.c (spu_catch_start): Likewise.
* config/djgpp/fnchange.lst: Add entries for
gdb/testsuite/gdb.base/break-fun-addr1.c and
gdb/testsuite/gdb.base/break-fun-addr2.c.
gdb/testsuite/ChangeLog:
* gdb.base/break-fun-addr.exp: New file.
* gdb.base/break-fun-addr1.c: New file.
* gdb.base/break-fun-addr2.c: New file.
The gnu_vector test case yields a new FAIL on s390x:
FAIL: gdb.base/gnu_vector.exp: verify vector return value
It was introduced by commit 77ae9c1933 "gdb.base/gnu_vector.exp:
Don't test output from the inferior". That commit dropped the special
handling for GDB's inability (on some targets) to set the return value.
This change re-establishes the logic from before, converting the above
FAIL to a KFAIL (PRMS gdb/8549).
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.exp: Re-establish handling for should_kfail
when GDB can not set the vector return value. Add more comments
for clarification.
This commit changes GDB like this:
- Program received signal SIGINT, Interrupt.
+ Thread 1 "main" received signal SIGINT, Interrupt.
- Breakpoint 1 at 0x40087a: file threads.c, line 87.
+ Thread 3 "bar" hit Breakpoint 1 at 0x40087a: file threads.c, line 87.
... once the program goes multi-threaded. Until GDB sees a second
thread spawn, the output is still the same as before, per the
discussion back in 2012:
https://www.sourceware.org/ml/gdb/2012-11/msg00010.html
This helps non-stop mode, where you can't easily tell which thread hit
a breakpoint or received a signal:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 19362) "main" (running)
2 Thread 0x7ffff7fc0700 (LWP 19366) "foo" (running)
3 Thread 0x7ffff77bf700 (LWP 19367) "bar" (running)
(gdb)
Program received signal SIGUSR1, User defined signal 1.
0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92
92 lll_wait_tid (pd->tid);
(gdb) b threads.c:87
Breakpoint 1 at 0x40087a: file threads.c, line 87.
(gdb)
Breakpoint 1, thread_function1 (arg=0x1) at threads.c:87
87 usleep (1); /* Loop increment. */
The best the user can do is run "info threads" and try to figure
things out.
It actually also affects all-stop mode, in case of "handle SIG print
nostop":
...
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
Program received signal SIGUSR1, User defined signal 1.
...
The above doesn't give any clue that these were different threads
getting the SIGUSR1 signal.
I initially thought of lowercasing "breakpoint" in
"Thread 3 hit Breakpoint 1"
but then after trying it I realized that leaving "Breakpoint"
uppercase helps the eye quickly find the relevant information. It's
also easier to implement not showing anything about threads until the
program goes multi-threaded this way.
Here's a larger example session in non-stop mode:
(gdb) c -a&
Continuing.
(gdb) interrupt -a
(gdb)
Thread 1 "main" stopped.
0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92
92 lll_wait_tid (pd->tid);
Thread 2 "foo" stopped.
0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
Thread 3 "bar" stopped.
0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
b threads.c:87
Breakpoint 4 at 0x40087a: file threads.c, line 87.
(gdb) b threads.c:67
Breakpoint 5 at 0x400811: file threads.c, line 67.
(gdb) c -a&
Continuing.
(gdb)
Thread 3 "bar" hit Breakpoint 4, thread_function1 (arg=0x1) at threads.c:87
87 usleep (1); /* Loop increment. */
Thread 2 "foo" hit Breakpoint 5, thread_function0 (arg=0x0) at threads.c:68
68 (*myp) ++;
info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" (running)
2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68
3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87
(gdb) shell kill -SIGINT 31957
(gdb)
Thread 1 "main" received signal SIGINT, Interrupt.
0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92
92 lll_wait_tid (pd->tid);
info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92
2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68
3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87
(gdb) t 2
[Switching to thread 2, Thread 0x7ffff7fc0700 (LWP 31961)]
#0 thread_function0 (arg=0x0) at threads.c:68
68 (*myp) ++;
(gdb) catch syscall
Catchpoint 6 (any syscall)
(gdb) c&
Continuing.
(gdb)
Thread 2 "foo" hit Catchpoint 6 (call to syscall nanosleep), 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
I'll work on documentation next if this looks agreeable.
This patch applies on top of the star wildcards thread IDs series:
https://sourceware.org/ml/gdb-patches/2016-01/msg00291.html
For convenience, I've pushed this to the
users/palves/show-which-thread-caused-stop branch.
gdb/doc/ChangeLog:
2016-01-18 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Mention that GDB displays the ID and name
of the thread that hit a breakpoint or received a signal.
gdb/ChangeLog:
2016-01-18 Pedro Alves <palves@redhat.com>
* NEWS: Mention that GDB now displays the ID and name of the
thread that hit a breakpoint or received a signal.
* break-catch-sig.c (signal_catchpoint_print_it): Use
maybe_print_thread_hit_breakpoint.
* break-catch-syscall.c (print_it_catch_syscall): Likewise.
* break-catch-throw.c (print_it_exception_catchpoint): Likewise.
* breakpoint.c (maybe_print_thread_hit_breakpoint): New function.
(print_it_catch_fork, print_it_catch_vfork, print_it_catch_solib)
(print_it_catch_exec, print_it_ranged_breakpoint)
(print_it_watchpoint, print_it_masked_watchpoint, bkpt_print_it):
Use maybe_print_thread_hit_breakpoint.
* breakpoint.h (maybe_print_thread_hit_breakpoint): Declare.
* gdbthread.h (show_thread_that_caused_stop): Declare.
* infrun.c (print_signal_received_reason): Print which thread
received signal.
* thread.c (show_thread_that_caused_stop): New function.
gdb/testsuite/ChangeLog:
2016-01-18 Pedro Alves <palves@redhat.com>
* gdb.base/async-shell.exp: Adjust expected output.
* gdb.base/dprintf-non-stop.exp: Adjust expected output.
* gdb.base/siginfo-thread.exp: Adjust expected output.
* gdb.base/watchpoint-hw-hit-once.exp: Adjust expected output.
* gdb.java/jnpe.exp: Adjust expected output.
* gdb.threads/clone-new-thread-event.exp: Adjust expected output.
* gdb.threads/continue-pending-status.exp: Adjust expected output.
* gdb.threads/leader-exit.exp: Adjust expected output.
* gdb.threads/manythreads.exp: Adjust expected output.
* gdb.threads/pthreads.exp: Adjust expected output.
* gdb.threads/schedlock.exp: Adjust expected output.
* gdb.threads/siginfo-threads.exp: Adjust expected output.
* gdb.threads/signal-command-multiple-signals-pending.exp: Adjust
expected output.
* gdb.threads/signal-delivered-right-thread.exp: Adjust expected
output.
* gdb.threads/sigthread.exp: Adjust expected output.
* gdb.threads/watchpoint-fork.exp: Adjust expected output.
This commit adds a new $_gthread convenience variable, that is like
$_thread, but holds the current thread's global thread id.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* NEWS: Mention $_gthread.
* gdbthread.h (struct thread_info) <global_num>: Mention
$_gthread.
* thread.c (thread_num_make_value_helper): New function.
(thread_id_make_value): Delete.
(thread_id_per_inf_num_make_value, global_thread_id_make_value):
New.
(thread_funcs): Adjust.
(gthread_funcs): New.
(_initialize_thread): Register $_gthread variable.
gdb/testsuite/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* gdb.base/default.exp: Expect $_gthread as well.
* gdb.multi/tids.exp: Test $_gthread.
* gdb.threads/thread-specific.exp: Test $_gthread.
gdb/doc/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Document the $_gthread convenience
variable.
(Convenience Vars): Likewise.
This commit changes GDB to track thread numbers per-inferior. Then,
if you're debugging multiple inferiors, GDB displays
"inferior-num.thread-num" instead of just "thread-num" whenever it
needs to display a thread:
(gdb) info inferiors
Num Description Executable
1 process 6022 /home/pedro/gdb/tests/threads
* 2 process 6037 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
1.1 Thread 0x7ffff7fc2740 (LWP 6022) "threads" (running)
1.2 Thread 0x7ffff77c0700 (LWP 6028) "threads" (running)
1.3 Thread 0x7ffff7fc2740 (LWP 6032) "threads" (running)
2.1 Thread 0x7ffff7fc1700 (LWP 6037) "threads" (running)
2.2 Thread 0x7ffff77c0700 (LWP 6038) "threads" (running)
* 2.3 Thread 0x7ffff7fc2740 (LWP 6039) "threads" (running)
(gdb)
...
(gdb) thread 1.1
[Switching to thread 1.1 (Thread 0x7ffff7fc2740 (LWP 8155))]
(gdb)
...
etc.
You can still use "thread NUM", in which case GDB infers you're
referring to thread NUM of the current inferior.
The $_thread convenience var and Python's InferiorThread.num attribute
are remapped to the new per-inferior thread number. It's a backward
compatibility break, but since it only matters when debugging multiple
inferiors, I think it's worth doing.
Because MI thread IDs need to be a single integer, we keep giving
threads a global identifier, _in addition_ to the per-inferior number,
and make MI always refer to the global thread IDs. IOW, nothing
changes from a MI frontend's perspective.
Similarly, since Python's Breakpoint.thread and Guile's
breakpoint-thread/set-breakpoint-thread breakpoint methods need to
work with integers, those are adjusted to work with global thread IDs
too. Follow up patches will provide convenient means to access
threads' global IDs.
To avoid potencially confusing users (which also avoids updating much
of the testsuite), if there's only one inferior and its ID is "1",
IOW, the user hasn't done anything multi-process/inferior related,
then the "INF." part of thread IDs is not shown. E.g,.:
(gdb) info inferiors
Num Description Executable
* 1 process 15275 /home/pedro/gdb/tests/threads
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb) add-inferior
Added inferior 2
(gdb) info threads
Id Target Id Frame
* 1.1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40
(gdb)
No regressions on x86_64 Fedora 20.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
* NEWS: Mention that thread IDs are now per inferior and global
thread IDs.
* Makefile.in (SFILES): Add tid-parse.c.
(COMMON_OBS): Add tid-parse.o.
(HFILES_NO_SRCDIR): Add tid-parse.h.
* ada-tasks.c: Adjust to use ptid_to_global_thread_id.
* breakpoint.c (insert_breakpoint_locations)
(remove_threaded_breakpoints, bpstat_check_breakpoint_conditions)
(print_one_breakpoint_location, set_longjmp_breakpoint)
(check_longjmp_breakpoint_for_call_dummy)
(set_momentary_breakpoint): Adjust to use global IDs.
(find_condition_and_thread, watch_command_1): Use parse_thread_id.
(until_break_command, longjmp_bkpt_dtor)
(breakpoint_re_set_thread, insert_single_step_breakpoint): Adjust
to use global IDs.
* dummy-frame.c (pop_dummy_frame_bpt): Adjust to use
ptid_to_global_thread_id.
* elfread.c (elf_gnu_ifunc_resolver_stop): Likewise.
* gdbthread.h (struct thread_info): Rename field 'num' to
'global_num. Add new fields 'per_inf_num' and 'inf'.
(thread_id_to_pid): Rename thread_id_to_pid to
global_thread_id_to_ptid.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(find_thread_id): Rename to ...
(find_thread_global_id): ... this.
(ALL_THREADS, ALL_THREADS_BY_INFERIOR): Declare.
(print_thread_info): Add comment.
* tid-parse.h: New file.
* tid-parse.c: New file.
* infcmd.c (step_command_fsm_prepare)
(step_command_fsm_should_stop): Adjust to use the global thread
ID.
(until_next_command, until_next_command)
(finish_command_fsm_should_stop): Adjust to use the global thread
ID.
(attach_post_wait): Adjust to check the inferior number too.
* inferior.h (struct inferior) <highest_thread_num>: New field.
* infrun.c (handle_signal_stop)
(insert_exception_resume_breakpoint)
(insert_exception_resume_from_probe): Adjust to use the global
thread ID.
* record-btrace.c (record_btrace_open): Use global thread IDs.
* remote.c (process_initial_stop_replies): Also consider the
inferior number.
* target.c (target_pre_inferior): Clear the inferior's highest
thread num.
* thread.c (clear_thread_inferior_resources): Adjust to use the
global thread ID.
(new_thread): New inferior parameter. Adjust to use it. Set both
the thread's global ID and the thread's per-inferior ID.
(add_thread_silent): Adjust.
(find_thread_global_id): New.
(find_thread_id): Make static. Adjust to rename.
(valid_thread_id): Rename to ...
(valid_global_thread_id): ... this.
(pid_to_thread_id): Rename to ...
(ptid_to_global_thread_id): ... this.
(thread_id_to_pid): Rename to ...
(global_thread_id_to_ptid): ... this. Adjust.
(first_thread_of_process): Adjust.
(do_captured_list_thread_ids): Adjust to use global thread IDs.
(should_print_thread): New function.
(print_thread_info): Rename to ...
(print_thread_info_1): ... this, and add new show_global_ids
parameter. Handle it. Iterate over inferiors.
(print_thread_info): Reimplement as wrapper around
print_thread_info_1.
(show_inferior_qualified_tids): New function.
(print_thread_id): Use it.
(tp_array_compar): Compare inferior numbers too.
(thread_apply_command): Use tid_range_parser.
(do_captured_thread_select): Use parse_thread_id.
(thread_id_make_value): Adjust.
(_initialize_thread): Adjust "info threads" help string.
* varobj.c (struct varobj_root): Update comment.
(varobj_create): Adjust to use global thread IDs.
(value_of_root_1): Adjust to use global_thread_id_to_ptid.
* windows-tdep.c (display_tib): No longer accept an argument.
* cli/cli-utils.c (get_number_trailer): Make extern.
* cli/cli-utils.h (get_number_trailer): Declare.
(get_number_const): Adjust documentation.
* mi/mi-cmd-var.c (mi_cmd_var_update_iter): Adjust to use global
thread IDs.
* mi/mi-interp.c (mi_new_thread, mi_thread_exit)
(mi_on_normal_stop, mi_output_running_pid, mi_on_resume):
* mi/mi-main.c (mi_execute_command, mi_cmd_execute): Likewise.
* guile/scm-breakpoint.c (gdbscm_set_breakpoint_thread_x):
Likewise.
* python/py-breakpoint.c (bppy_set_thread): Likewise.
* python/py-finishbreakpoint.c (bpfinishpy_init): Likewise.
* python/py-infthread.c (thpy_get_num): Add comment and return the
per-inferior thread ID.
(thread_object_getset): Update comment of "num".
gdb/testsuite/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.base/break.exp: Adjust to output changes.
* gdb.base/hbreak2.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/watch_thread_num.exp: Likewise.
* gdb.linespec/keywords.exp: Likewise.
* gdb.multi/info-threads.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.multi/tids.c: New file.
* gdb.multi/tids.exp: New file.
gdb/doc/ChangeLog:
2016-01-07 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Threads): Document per-inferior thread IDs,
qualified thread IDs, global thread IDs and thread ID lists.
(Set Watchpoints, Thread-Specific Breakpoints): Adjust to refer to
thread IDs.
(Convenience Vars): Document the $_thread convenience variable.
(Ada Tasks): Adjust to refer to thread IDs.
(GDB/MI Async Records, GDB/MI Thread Commands, GDB/MI Ada Tasking
Commands, GDB/MI Variable Objects): Update to mention global
thread IDs.
* guile.texi (Breakpoints In Guile)
<breakpoint-thread/set-breakpoint-thread breakpoint>: Mention
global thread IDs instead of thread IDs.
* python.texi (Threads In Python): Adjust documentation of
InferiorThread.num.
(Breakpoint.thread): Mention global thread IDs instead of thread
IDs.
This commit merges both the registers and $_siginfo "thread
running/executing" checks into a single function.
Accessing $_siginfo from a "catch signal" breakpoint condition doesn't
work. The condition always fails with "Selected thread is running":
(gdb) catch signal
Catchpoint 3 (standard signals)
(gdb)
condition $bpnum $_siginfo.si_signo == 5
(gdb) continue
Continuing.
Error in testing breakpoint condition:
Selected thread is running.
Catchpoint 3 (signal SIGUSR1), 0x0000003615e35877 in __GI_raise (sig=10) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb)
When accessing the $_siginfo object, we check whether the thread is
marked running (external/public) state and refuse the access if so.
This is so "print $_siginfo" at the prompt fails nicelly when the
current thread is running. While evaluating breakpoint conditionals,
we haven't decided yet whether the thread is going to stop, so
is_running still returns true, and we thus always error out.
Evaluating an expression that requires registers access is really
conceptually the same -- we could think of $_siginfo as a pseudo
register. However, in that case we check whether the thread is marked
executing (internal/private state), not running (external/public
state). Changing the $_siginfo validation to check is_executing as
well fixes the bug in question.
Note that checking is_executing is not fully correct, not even for
registers. See PR 19389. However, I think this is the lesser of two
evils and ends up as an improvement. We at least now have a single
place to fix.
Tested on x86_64 GNU/Linux.
gdb/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
PR breakpoints/19388
* frame.c (get_current_frame): Use validate_registers_access.
* gdbthread.h (validate_registers_access): Declare.
* infrun.c (validate_siginfo_access): Delete.
(siginfo_value_read, siginfo_value_write): Use
validate_registers_access.
* thread.c (validate_registers_access): New function.
gdb/testsuite/ChangeLog:
2016-01-13 Pedro Alves <palves@redhat.com>
PR breakpoints/19388
* gdb.base/catch-signal-siginfo-cond.c: New file.
* gdb.base/catch-signal-siginfo-cond.exp: New file.
This adds a new QCatchSyscalls packet to enable 'catch syscall', and new
stop reasons "syscall_entry" and "syscall_return" for those events. It
is currently only supported on Linux x86 and x86_64.
gdb/ChangeLog:
2016-01-12 Josh Stone <jistone@redhat.com>
Philippe Waroquiers <philippe.waroquiers@skynet.be>
* NEWS (Changes since GDB 7.10): Mention QCatchSyscalls and the
syscall_entry and syscall_return stop reasons. Mention GDB
support for remote catch syscall.
* remote.c (PACKET_QCatchSyscalls): New enum.
(remote_set_syscall_catchpoint): New function.
(remote_protocol_features): New element for QCatchSyscalls.
(remote_parse_stop_reply): Parse syscall_entry/return stops.
(init_remote_ops): Install remote_set_syscall_catchpoint.
(_initialize_remote): Config QCatchSyscalls.
* linux-nat.h (struct lwp_info) <syscall_state>: Comment typo.
gdb/doc/ChangeLog:
2016-01-12 Josh Stone <jistone@redhat.com>
Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.texinfo (Remote Configuration): List the QCatchSyscalls packet.
(Stop Reply Packets): List the syscall entry and return stop reasons.
(General Query Packets): Describe QCatchSyscalls, and add it to the
table and the detailed list of stub features.
gdb/gdbserver/ChangeLog:
2016-01-12 Josh Stone <jistone@redhat.com>
Philippe Waroquiers <philippe.waroquiers@skynet.be>
* inferiors.h: Include "gdb_vecs.h".
(struct process_info): Add syscalls_to_catch.
* inferiors.c (remove_process): Free syscalls_to_catch.
* remote-utils.c (prepare_resume_reply): Report syscall_entry and
syscall_return stops.
* server.h (UNKNOWN_SYSCALL, ANY_SYSCALL): Define.
* server.c (handle_general_set): Handle QCatchSyscalls.
(handle_query): Report support for QCatchSyscalls.
* target.h (struct target_ops): Add supports_catch_syscall.
(target_supports_catch_syscall): New macro.
* linux-low.h (struct linux_target_ops): Add get_syscall_trapinfo.
(struct lwp_info): Add syscall_state.
* linux-low.c (handle_extended_wait): Mark syscall_state as an entry.
Maintain syscall_state and syscalls_to_catch across exec.
(get_syscall_trapinfo): New function, proxy to the_low_target.
(linux_low_ptrace_options): Enable PTRACE_O_TRACESYSGOOD.
(linux_low_filter_event): Toggle syscall_state entry/return for
syscall traps, and set it ignored for all others.
(gdb_catching_syscalls_p): New function.
(gdb_catch_this_syscall_p): New function.
(linux_wait_1): Handle SYSCALL_SIGTRAP.
(linux_resume_one_lwp_throw): Add PTRACE_SYSCALL possibility.
(linux_supports_catch_syscall): New function.
(linux_target_ops): Install it.
* linux-x86-low.c (x86_get_syscall_trapinfo): New function.
(the_low_target): Install it.
gdb/testsuite/ChangeLog:
2016-01-12 Josh Stone <jistone@redhat.com>
Philippe Waroquiers <philippe.waroquiers@skynet.be>
* gdb.base/catch-syscall.c (do_execve): New variable.
(main): Conditionally trigger an execve.
* gdb.base/catch-syscall.exp: Enable testing for remote targets.
(test_catch_syscall_execve): New, check entry/return across execve.
(do_syscall_tests): Call test_catch_syscall_execve.
This exposes the issued fixed by 2f99e8fc9cb8:
https://sourceware.org/ml/gdb-patches/2015-12/msg00423.html
to native debugging as well.
gdb/testsuite/ChangeLog:
2016-01-12 Pedro Alves <palves@redhat.com>
* gdb.base/random-signal.exp (do_test): New procedure, with body
of testcase moved in.
(top level) Call it twice, once with "run" and once with "attach".
[This reapplies a change that was accidentally reverted with c0ecb95f3d.]
Before:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
gdb/doc/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.texinfo (Inferiors and Programs): Adjust "maint info
program-spaces" example to ascending order listing.
(Threads): Adjust "info threads" example to ascending order
listing.
(Forks): Adjust "info inferiors" example to ascending order
listing.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* inferior.c (add_inferior_silent): Append the new inferior to the
end of the list.
* progspace.c (add_program_space): Append the new pspace to the
end of the list.
* thread.c (new_thread): Append the new thread to the end of the
list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
threads in ascending order.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/multi-forks.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.multi/base.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.threads/break-while-running.exp: Likewise.
* gdb.threads/execl.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* gdb.threads/info-threads-cur-sal.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/multiple-step-overs.exp: Likewise.
* gdb.threads/next-bp-other-thread.exp: Likewise.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
* lib/mi-support.exp (mi_reverse_list): Delete.
(mi_check_thread_states): No longer reverse list.
3ca22649a6 is the first bad commit
commit 3ca22649a6
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date: Mon Dec 21 12:51:54 2015 -0500
Remove HP-UX references fom testsuite
@@ -1013,13 +1013,6 @@ proc localvars_in_indirect_call { } {
#
gdb_test_multiple "finish" "finish from indirectly called function" {
- -re "\\(\\*pointer_to_call0a\\) \\(c, s, i, l\\);.*First.*$gdb_prompt $" {
- #On hppa2.0w-hp-hpux11.00, gdb finishes at one line earlier than
- #hppa1.1-hp-hpux11.00. Therefore, an extra "step" is necessary
- #to continue the test.
- send_gdb "step\n"
- exp_continue
- }
-re ".*\\(\\*pointer_to_call0a\\) \\(c, s, i, l\\);.*Second.*$gdb_prompt $" {
pass "finish from indirectly called function"
}
->
finish^M
Run till exit from #0 call0a (c=97 'a', s=1, i=2, l=3) at ./gdb.base/funcargs.c:82^M
0x0804a189 in main () at ./gdb.base/funcargs.c:583^M
583 (*pointer_to_call0a) (c, s, i, l); /* First step into call0a. */^M
-(gdb) step^M
-584 (*pointer_to_call0a) (c, s, i, l); /* Second step into call0a. */^M
-(gdb) PASS: gdb.base/funcargs.exp: finish from indirectly called function
+(gdb) FAIL: gdb.base/funcargs.exp: finish from indirectly called function
step^M
-call0a (c=97 'a', s=1, i=2, l=3) at ./gdb.base/funcargs.c:82^M
-82 c = 'a';^M
-(gdb) PASS: gdb.base/funcargs.exp: stepping into indirectly called function
+584 (*pointer_to_call0a) (c, s, i, l); /* Second step into call0a. */^M
+(gdb) FAIL: gdb.base/funcargs.exp: stepping into indirectly called function
At least on x86_64 with testsuite in -m32 (expecting native i386 would be the
same).
Pedro Alves:
The difference is that with newer GCC there's an extra instruction
after the call which is still assigned to line 583:
$ diff -up /tmp/4.8.3 /tmp/6.0.0 -U 1000
--- /tmp/4.8.3 2016-01-11 12:37:39.611089156 +0000
+++ /tmp/6.0.0 2016-01-11 13:21:00.021127976 +0000
@@ -1,27 +1,30 @@
583 (*pointer_to_call0a) (c, s, i, l); /* First step into call0a. */
mov 0x804d060,%ebx
mov 0x804d050,%ecx
movzwl 0x804d040,%eax
movswl %ax,%edx
movzbl 0x804d030,%eax
movsbl %al,%eax
- mov %ebx,0xc(%esp)
- mov %ecx,0x8(%esp)
- mov %edx,0x4(%esp)
- mov %eax,(%esp)
- mov 0x7c(%esp),%eax
+ push %ebx
+ push %ecx
+ push %edx
+ push %eax
+ mov -0x1c(%ebp),%eax
call *%eax
+ add $0x10,%esp
584 (*pointer_to_call0a) (c, s, i, l); /* Second step into call0a. */
mov 0x804d060,%ebx
mov 0x804d050,%ecx
movzwl 0x804d040,%eax
movswl %ax,%edx
movzbl 0x804d030,%eax
movsbl %al,%eax
- mov %ebx,0xc(%esp)
- mov %ecx,0x8(%esp)
- mov %edx,0x4(%esp)
- mov %eax,(%esp)
- mov 0x7c(%esp),%eax
+ push %ebx
+ push %ecx
+ push %edx
+ push %eax
+ mov -0x1c(%ebp),%eax
call *%eax
+ add $0x10,%esp
+
I don't know why -m32 changed to push/add instead of mov while 64-bit hasn't.
This is most likely needed on non-x86 ports as well.
gdb/testsuite/ChangeLog
2016-01-11 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/funcargs.exp (finish from indirectly called function):
Reintroduce the case for 'First'.
fe33faff35 is the first bad commit
commit fe33faff35
Author: Simon Marchi <simon.marchi@ericsson.com>
Date: Tue Dec 22 10:52:31 2015 -0500
Remove HP-UX reference in foll-vfork.exp
FAIL: gdb.base/foll-vfork.exp: exec: vfork parent follow, finish after tcatch vfork: continue to vfork
FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: continue to vfork
FAIL: gdb.base/foll-vfork.exp: exit: vfork parent follow, finish after tcatch vfork: continue to vfork
FAIL: gdb.base/foll-vfork.exp: exit: vfork child follow, finish after tcatch vfork: continue to vfork
It happens for plain gdb.base/foll-vfork.exp runtest on Fedora 23 x86_64.
-Temporary catchpoint 2 (vforked process 24562), vfork () at ../sysdeps/unix/sysv/linux/x86_64/vfork.S:52^M
+Temporary catchpoint 2 (vforked process 25345), vfork () at ../sysdeps/unix/sysv/linux/x86_64/vfork.S:52^M
52 pushq %rdi^M
Current language: auto^M
The current source language is "auto; currently asm".^M
-(gdb) PASS: gdb.base/foll-vfork.exp: exec: vfork parent follow, finish after tcatch vfork: continue to vfork
+(gdb) FAIL: gdb.base/foll-vfork.exp: exec: vfork parent follow, finish after tcatch vfork: continue to vfork
-Temporary catchpoint 2 (vforked process 24629), vfork () at ../sysdeps/unix/sysv/linux/x86_64/vfork.S:52^M
+Temporary catchpoint 2 (vforked process 25411), vfork () at ../sysdeps/unix/sysv/linux/x86_64/vfork.S:52^M
52 pushq %rdi^M
Current language: auto^M
The current source language is "auto; currently asm".^M
-(gdb) PASS: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: continue to vfork
+(gdb) FAIL: gdb.base/foll-vfork.exp: exec: vfork child follow, finish after tcatch vfork: continue to vfork
So I have reverted it and just simplified the comment.
The third case is not necessary during testing but I have changed back all the
3 cases.
Pedro Alves:
I know it was that way before, but would you mind moving this to a helper
proc.
gdb/testsuite/ChangeLog
2016-01-11 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.base/foll-vfork.exp (tcatch_vfork_then_parent_follow)
(tcatch_vfork_then_child_follow_exec)
(tcatch_vfork_then_child_follow_exit): Revert back DWARF vfork
identification.
I was getting
gu (print arg0)^M
= 0x7fffffffdafb
"/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.guile/scm-value/scm-"...^M
(gdb) FAIL: gdb.guile/scm-value.exp: verify dereferenced value
python print (arg0)^M
0x7fffffffdafd
"/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.python/py-value/py-v"...^M
(gdb) FAIL: gdb.python/py-value.exp: verify dereferenced value
and also:
(gdb) p argv[0]^M
$2 = 0x7fffffffd832 "/home/jkratoch/redhat/gdb-test-", 'x' <repeats 169
times>...^M
(gdb) FAIL: gdb.guile/scm-value.exp: argv[0] should be available on this
target
gdb/testsuite/ChangeLog
2016-01-11 Jan Kratochvil <jan.kratochvil@redhat.com>
* gdb.guile/scm-value.exp (test_value_in_inferior): Set print elements
and repeats to unlimited.
* gdb.python/py-value.exp: Likewise.
* lib/gdb.exp (gdb_has_argv0): Save and temporarily set print elements
and repeats to unlimited.
One more I just found.
Tested with native, native-gdbserver and native-extended-gdbserver on
Linux.
gdb/testsuite/ChangeLog:
* gdb.base/foll-vork.exp: Remove HP-UX special case.
This patch removes cases from the testsuite that are not posssibly used. The
messages "Catch of * not yet implemented" were removed here:
https://www.sourceware.org/ml/gdb-patches/2004-01/msg00679.html
I changed the regexp at the same time to match the string more closely.
gdb/testsuite/ChangeLog:
* gdb.base/break.exp: Remove dead code.
* gdb.base/sepdebug.exp: Likewise.
This patch removes all special cases for HP-UX, for which support has
been removed earlier, that I found in the testsuite. Note that the hppa
architecture != HP-UX, since other OSes can run on hppa, so I tried to
leave everything that is not HP-UX specific.
Two complete tests were completely HP-UX specific, so I removed them.
I ran the testsuite on Linux x86-64, native and native-gdbserver, and
noticed no regressions.
gdb/testsuite/ChangeLog:
* gdb.asm/asm-source.exp: Remove HP-UX references.
* gdb.base/annota1.exp: Likewise.
* gdb.base/annota3.exp: Likewise.
* gdb.base/attach.exp: Likewise.
* gdb.base/bigcore.exp: Likewise.
* gdb.base/break.exp: Likewise.
* gdb.base/call-ar-st.exp: Likewise.
* gdb.base/callfuncs.exp: Likewise.
* gdb.base/catch-fork-static.exp: Likewise.
* gdb.base/display.exp: Likewise.
* gdb.base/foll-exec-mode.exp: Likewise.
* gdb.base/foll-exec.exp: Likewise.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/funcargs.exp: Likewise.
* gdb.base/hbreak2.exp: Likewise.
* gdb.base/inferior-died.exp: Likewise.
* gdb.base/interrupt.exp: Likewise.
* gdb.base/multi-forks.exp: Likewise.
* gdb.base/nodebug.exp: Likewise.
* gdb.base/sepdebug.exp: Likewise.
* gdb.base/solib1.c: Likewise.
* gdb.base/step-test.exp: Likewise.
* gdb.mi/non-stop.c: Likewise.
* gdb.mi/pthreads.c: Likewise.
* gdb.multi/bkpt-multi-exec.ex: Likewise.
* gdb.threads/pthreads.c: Likewise.
* gdb.threads/staticthreads.exp: Likewise.
* lib/future.exp: Likewise.
* lib/gdb.exp: Likewise.
* gdb.base/so-indr-cl.c: Remove.
* gdb.base/so-indr-cl.exp: Likewise.
* gdb.base/solib.c: Likewise.
* gdb.base/solib.exp: Likewise.
* gdb.base/solib2.c: Likewise.
This patch updates tests for fork and exec events in target remote mode.
In the majority of cases this was a simple matter of removing some code
that disabled the test for target remote. In a few cases the test needed
to be disabled; in those cases the gdb_protocol was checked instead of
using the [is_remote target] etc.
In a couple of cases we needed to use clean_restart, since target remote
doesn't support the run command, and in one case we had to modify an expect
expression to allow for a "multiprocess-style" ptid.
Tested with the patch that implemented target remote mode fork and exec
event support.
gdb/testsuite/ChangeLog:
* gdb.base/execl-update-breakpoints.exp (main): Enable for target
remote.
* gdb.base/foll-exec-mode.exp (main): Disable for target remote.
* gdb.base/foll-exec.exp (main): Enable for target remote.
* gdb.base/foll-fork.exp (main): Likewise.
* gdb.base/foll-vfork.exp (main): Likewise.
* gdb.base/multi-forks.exp (main): Likewise, and use clean_restart.
(proc continue_to_exit_bp_loc): Use clean_restart.
* gdb.base/pie-execl.exp (main): Disable for target remote.
* gdb.base/watch-vfork.exp (main): Enable for target remote.
* gdb.mi/mi-nsthrexec.exp (main): Likewise.
* gdb.threads/execl.exp (main): Likewise.
* gdb.threads/fork-child-threads.exp (main): Likewise.
* gdb.threads/fork-plus-threads.exp (main): Disable for target
remote.
* gdb.threads/fork-thread-pending.exp (main): Enable for target
remote.
* gdb.threads/linux-dp.exp (check_philosopher_stack): Allow
pid.tid style ptids, instead of just tid.
* gdb.threads/thread-execl.exp (main): Enable for target remote.
* gdb.threads/watchpoint-fork.exp (main): Likewise.
* gdb.trace/report.exp (use_collected_data): Allow pid.tid style
ptids, instead of just tid.
When a a user uses 'list +' to list forward through a source file they
eventually reach the end of the source file. Subsequent uses of 'list
+' result in an error message like this, that let the user know they are
at the end of the source file:
Line number XXX out of range; FILENAME has YYY lines.
Compare this to the current behaviour of 'list -' which lists backwards
through a source file. When the user reaches the beginning of the
source file, subsequent uses of 'list -' result in the command silently
returning. This can be confusing if the previous uses of 'list -' have
scrolled off the users display, the user receives no reminder that the
have already seen the start of the file.
After this commit a use of 'list -' when the user has already seen the
start of a file will receive the following error:
Already at the start of FILENAME.
gdb/ChangeLog:
* cli/cli-cmds.c (list_command): Add an error when trying to use
'-' to scan read off the start of the source file.
gdb/testsuite/ChangeLog:
* gdb.base/list.exp (test_list_forward): Add end of file error
test.
(test_repeat_list_command): Add end of file error test.
(test_list_backwards): Add beginning of file error test.
There is an inconsistency with the handling of the special +/- arguments
to the list command.
For the very first time that list is used (after the inferior has
changed locations) then only the first character of the argument string
is checked, so 'list +BLAH' will operate as 'list +' and 'list -----FOO'
will operate as 'list -'. This compares to each subsequent use of list,
where the whole argument string is checked, so 'list +BLAH' will try to
list lines of code around the function '+BLAH'.
This commit unifies the behaviour so that the whole argument string is
checked, in order to list the next 10, or previous 10 lines from a file
only 'list +' and 'list -' are now valid.
gdb/ChangeLog:
* cli/cli-cmds.c (list_command): Check that the argument string is
a single character, either '+' or '-'.
gdb/testsuite/ChangeLog:
* gdb.base/list.exp (test_list_invalid_args): New function,
defined, and called.
I happen to find that coremaker2.c isn't used in the testsuite (if I
don't miss anything). I don't believe it until I see this ChangeLog
entry,
1999-11-18 Fred Fish <fnf@cygnus.com>
* gdb.base/coremaker2.c: Add sample program for generating
cores that is more self contained than coremaker.c. Eventually
I'll add more code to this and tie it into the testsuite.
looks Fred didn't "tie it into testsuite" later.
gdb/testsuite:
2015-12-11 Yao Qi <yao.qi@linaro.org>
* gdb.base/coremaker2.c: Remove.
This change eliminates some failures on simulator targets and makes
the test run a bit quicker too - without this change, we have to wait
for timeouts.
gdb/testsuite/ChangeLog:
* gdb.base/async.exp (proc test_background): Add case
for asynchronous execution not supported.
Rename target_ops.arch_setup to .post_create_inferior. In the Linux
hook, continue calling the low arch setup, then also set ptrace flags.
This corrects the possibility of running without flags, demonstrated by
a new test that would fail to catch a fork before.
gdb/gdbserver/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* target.h (struct target_ops) <arch_setup>: Rename to ...
(struct target_ops) <post_create_inferior>: ... this.
(target_arch_setup): Rename to ...
(target_post_create_inferior): ... this, calling post_create_inferior.
* server.c (start_inferior): Update target_arch_setup calls to
target_post_create_inferior.
* linux-low.c (linux_low_ptrace_options): Forward declare.
(linux_arch_setup): Update its comment for general use.
(linux_post_create_inferior): New, run arch_setup and setup ptrace.
(struct linux_target_ops): Use linux_post_create_inferior.
* lynx-low.c (struct lynx_target_ops): Update arch_setup stub comment
to post_create_inferior.
* nto-low.c (struct nto_target_ops): Likewise.
* spu-low.c (struct spu_target_ops): Likewise.
* win32-low.c (struct win32_target_ops): Likewise.
gdb/testsuite/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* gdb.base/catch-fork-static.exp: New.
In my remote cross testing (x86_64 host and aarch64 target), the test
gdb.base/sizeof.exp is skipped because gdb,noinferiorio is defined in
my gdbserver board file. Tests are skipped because the test checks
the expected value from the program's output, but I don't see why must
do it this way. With my patch applied, we can save the result in variable
in the program, and check the variable then. Then, the test doesn't rely
on inferiorio.
gdb/testsuite:
2015-12-03 Yao Qi <yao.qi@linaro.org>
* gdb.base/sizeof.c: Don't include stdio.h and
../lib/unbuffer_output.c.
(main): New variable 'size' and 'value'. Remove printf and
gdb_unbuffer_output. Assign return value to size and value.
* gdb.base/sizeof.exp: Remove the checking to gdb,noinferiorio
at the beginning.
(check_sizeof): Check the result by printing variable 'size'.
(check_valueof): Check the result by printing variable 'value'.
Testing with the extended-remote board with "maint set target-non-stop
on" shows a dprintf-non-stop.exp regression. The issue is simply that
the test is expecting output that is only valid for the native target:
native:
[process 8676] #1 stopped.
remote:
[Thread 8900.8900] #1 stopped.
In order to expose this without "maint set target-non-stop on", this
restarts gdb with non-stop mode already enabled.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf-non-stop.exp: Use build_executable instead of
prepare_for_testing. Start gdb with "set non-stop on" appended to
GDBFLAGS. Lax expected stop output.
Before:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
3: y 1
2: y 1
1: y 1
After:
(gdb) info display
Auto-display expressions now in effect:
Num Enb Expression
1: y 1
2: y 1
3: y 1
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Before:
(gdb) info checkpoints
3 process 29132 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
After:
(gdb) info checkpoints
* 0 Thread 0x7ffff7fc5740 (LWP 29128) (main process) at 0x4008ad, file foo.c, line 81
1 process 29130 at 0x4008ad, file foo.c, line 81
2 process 29131 at 0x4008ad, file foo.c, line 81
3 process 29132 at 0x4008ad, file foo.c, line 81
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* printcmd.c (display_command): Append new display at the end of
the list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/display.exp: Expect displays to be sorted in ascending
order. Use multi_line.
* gdb.base/solib-display.exp: Likewise.
Before:
(gdb) info threads
Id Target Id Frame
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
After:
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92
2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60
3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30
gdb/doc/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.texinfo (Inferiors and Programs): Adjust "maint info
program-spaces" example to ascending order listing.
(Threads): Adjust "info threads" example to ascending order
listing.
(Forks): Adjust "info inferiors" example to ascending order
listing.
gdb/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* inferior.c (add_inferior_silent): Append the new inferior to the
end of the list.
* progspace.c (add_program_space): Append the new pspace to the
end of the list.
* thread.c (new_thread): Append the new thread to the end of the
list.
gdb/testsuite/ChangeLog:
2015-11-24 Pedro Alves <palves@redhat.com>
PR 17539
* gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and
threads in ascending order.
* gdb.base/foll-fork.exp: Likewise.
* gdb.base/foll-vfork.exp: Likewise.
* gdb.base/multi-forks.exp: Likewise.
* gdb.mi/mi-nonstop.exp: Likewise.
* gdb.mi/mi-nsintrall.exp: Likewise.
* gdb.multi/base.exp: Likewise.
* gdb.multi/multi-arch.exp: Likewise.
* gdb.python/py-inferior.exp: Likewise.
* gdb.threads/break-while-running.exp: Likewise.
* gdb.threads/execl.exp: Likewise.
* gdb.threads/gcore-thread.exp: Likewise.
* gdb.threads/info-threads-cur-sal.exp: Likewise.
* gdb.threads/kill.exp: Likewise.
* gdb.threads/linux-dp.exp: Likewise.
* gdb.threads/multiple-step-overs.exp: Likewise.
* gdb.threads/next-bp-other-thread.exp: Likewise.
* gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise.
* gdb.threads/step-over-lands-on-breakpoint.exp: Likewise.
* gdb.threads/step-over-trips-on-watchpoint.exp: Likewise.
* gdb.threads/thread-find.exp: Likewise.
* gdb.threads/tls.exp: Likewise.
* lib/mi-support.exp (mi_reverse_list): Delete.
(mi_check_thread_states): No longer reverse list.
The comment for the code in question says:
/* If the minimal symbol has a zero size, save it
but keep scanning backwards looking for one with
a non-zero size. A zero size may mean that the
symbol isn't an object or function (e.g. a
label), or it may just mean that the size was not
specified. */
As written, the code in question will only scan past the first symbol
of zero size. My change fixes the implementation to match the
comment.
Having this correct is important when the compiler generates several
local labels that are left in place by the linker. (I've been told
that the linker should eliminate these symbols, but I know of one
architecture for which this is not happening.)
I've created a test case called asmlabel.c. It's pretty simple:
main (int argc, char **argv)
{
asm ("L0:");
v = 0;
asm ("L1:");
v = 1; /* set L1 breakpoint here */
asm ("L2:");
v = 2; /* set L2 breakpoint here */
return 0;
}
If breakpoints are placed on the lines indicated by the comments,
this is the behavior of GDB built without my patch:
(gdb) continue
Continuing.
Breakpoint 2, L1 () at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
Note that L1 appears as the function instead of main. This is not
what we want to happen. With my patch in place, we see the desired
behavior instead:
(gdb) continue
Continuing.
Breakpoint 2, main (argc=1, argv=0x7fffffffdb88) at asmlabel.c:26
26 v = 1; /* set L1 breakpoint here */
gdb/ChangeLog:
* minsyms.c (lookup_minimal_symbol_by_pc_section_1): Scan backwards
over all zero-sized symbols.
gdb/testsuite/ChangeLog:
* gdb.base/asmlabel.exp: New test.
* gdb.base/asmlabel.c: New test case.
One of our users reported an internal error using the "bt full"
command. In their situation, reproducing involved the following
scenario:
(gdb) frame 1
(gdb) bt full
#0 0xf7783430 in __kernel_vsyscall ()
No symbol table info available.
#1 0xf5550aeb in waitpid () at ../sysdeps/unix/syscall-template.S:81
No locals.
[...]
#6 0x0fe83139 in xxxx (arg=...)
[...some locals printed, and then...]
<S17b> =
[...]/dwarf2loc.c:364: internal-error: dwarf_expr_frame_base: Assertion
`framefunc != NULL' failed.
As shown above, the error happens while GDB is trying to print the value
of <S17b>, which is a local string internally generated by the compiler.
For that, it finds that the array lives in memory, and therefore tries
to create a struct value for it via:
case DWARF_VALUE_MEMORY:
{
CORE_ADDR address = dwarf_expr_fetch_address (ctx, 0);
[...]
retval = value_at_lazy (type, address + byte_offset);
Unfortunately for us, TYPE happens to be an array whose bounds
are dynamic. More precisely, the bounds of our arrays are described
in the debugging info as being...
<4><2c1985e>: Abbrev Number: 33 (DW_TAG_subrange_type)
<2c1985f> DW_AT_type : <0x2c1989c>
<2c19863> DW_AT_lower_bound : <0x2c19835>
<2c19867> DW_AT_upper_bound : <0x2c19841>
... which are references to a pair of local variables. For instance,
the lower bound is a reference to the following DIE
<3><2c19835>: Abbrev Number: 32 (DW_TAG_variable)
<2c19836> DW_AT_name : [...]
<2c1983a> DW_AT_type : <0x2c198b4>
<2c1983e> DW_AT_artificial : 1
<2c1983e> DW_AT_location : 2 byte block: 91 58 (DW_OP_fbreg: -40)
As a result of the above, value_at_lazy indirectly triggers
a resolution of TYPE (via value_from_contents_and_address),
which means a resolution of TYPE's bounds, and as seen in
the DW_AT_location attribute above for our bounds, computing
the bound's location requires the frame (its location expression
uses DW_OP_fbreg).
Unfortunately for us, value_at_lazy does not get passed a frame,
we've lost the relevant frame when we try to resolve the array's
bounds. Instead, resolve_dynamic_range gets calls dwarf2_evaluate_property
with NULL as the frame:
static struct type *
resolve_dynamic_range (struct type *dyn_range_type,
struct property_addr_info *addr_stack)
{
[...]
if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value))
^^^^
... which then handles this by using the selected frame instead:
if (frame == NULL && has_stack_frames ())
frame = get_selected_frame (NULL);
In our case, the selected frame happens to be frame #1, which is
a frame where we have a minimal amount of debugging info, and in
particular, no debug info for the function itself. And because of that,
when we try to determine the frame's base...
static void
dwarf_expr_frame_base (void *baton, const gdb_byte **start,
size_t * length)
{
struct dwarf_expr_baton *debaton = (struct dwarf_expr_baton *) baton;
const struct block *bl = get_frame_block (debaton->frame, NULL);
[...]
framefunc = block_linkage_function (bl);
... framefunc ends up being NULL, which triggers the assert
in that same function:
gdb_assert (framefunc != NULL);
This patches avoids the issue by temporarily setting the selected_frame
before printing the locals of each frames.
This patch also adds a small testcase, which reproduces the same
issue, but with a slightly different outcome:
(gdb) bt full
#0 0x000000000040049a in opaque_routine ()
No symbol table info available.
#1 0x0000000000400532 in main () at wrong_frame_bt_full-main.c:20
my_table_size = 3
my_table = <error reading variable my_table (frame address is not available.)>
With this patch, the output becomes:
(gdb) bt full
[...]
my_table = {0, 1, 2}
gdb/ChangeLog:
* stack.c (print_frame_local_vars): Temporarily set the selected
frame to FRAME while printing the frame's local variables.
gdb/testsuite/ChangeLog:
* gdb.base/wrong_frame_bt_full-main.c: New file.
* gdb.base/wrong_frame_bt_full-opaque.c: New file.
* gdb.base/wrong_frame_bt_full.exp: New file.
The Linux kernel disables the FPU upon returning to userland. This
introduces spurious failures in the register preservation tests in
callfuncs.exp, since the pstate.PEF bit gets cleared after system
calls.
This patch filters out the pstate register in sparc64-*-linux-gnu
targets, so the relevant tests are no longer fooled and pass.
gdb/testsuite/ChangeLog:
2015-11-20 Jose E. Marchesi <jose.marchesi@oracle.com>
* gdb.base/callfuncs.exp (fetch_all_registers): Filter out the
pstate register when comparing registers values in
sparc64-*-linux-gnu targets to avoid spurious differences.
This patch removes the leftover of the d10v stuff in the testsuite
directory. The d10v port was removed in GDB 6.7, but I happen to see
that there are still some leftovers about d10v in testsuite.
gdb/testsuite:
2015-11-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/call-sc.exp (test_scalar_returns): Remove the
comments about d10v.
(test_scalar_returns): Likewise.
* gdb.base/d10v.ld: Remove.
* gdb.base/overlays.exp: Remove the target triplet checking for
d10v-*-*.
* gdb.base/structs.exp (test_struct_returns): Remove the
comments about d10v.
(test_struct_calls): Likewise.
gdb.base/gnu_vector.c printf the vector and gdb.base/gnu_vector.exp
expects the output by gdb_test_multiple. Nowadays, the test doesn't
expect the output from inferior_spawn_id, which is wrong. Even we
change the test to expect from inferior_spawn_id for the inferior
output, it is still possible the inferior exit before tcl/expect gets
the inferior output. We see this fail on both s390x-linux and
ppc-linux on buildbot,
FAIL: gdb.base/gnu_vector.exp: verify vector return value (the program exited)
https://sourceware.org/ml/gdb-testers/2015-q4/msg04922.htmlhttps://sourceware.org/ml/gdb-testers/2015-q4/msg04952.html
In order to address these two shortcomings above in gnu_vector.exp,
this patch rewrites the test a little bit. Get rid of checking the
inferior output, and instead checking them by printing them. In this
way, the test can also be run on the target without inferior io
(gdb,noinferiorio is set in the board file).
gdb/testsuite:
2015-11-13 Yao Qi <yao.qi@linaro.org>
* gdb.base/gnu_vector.exp: Check the return value by "p res".
* gdb.base/gnu_vector.c: Don't include stdio.h.
(main): Don't print res and call add_some_intvecs.
Nowadays, in the range-stepping tests, we check not only the number of
vCont;r packets but also the number of vCont;s packets, because we think
the remote target which can do range stepping must support single step.
However, if we turn displaced stepping on, the remote target (GDBserver)
can do range stepping, and support single step, but GDB may decide to
resume instructions in the scratchpad rather than single step them one
by one for displaced stepping. For example, when aarch64 GDB debugs
arm linux program with aarch64 GDBserver, GDBserver supports both range
stepping and single step, but GDB (with the gdbarch for arm-linux)
decides resume instructions in the scratchpad, so in the RSP traffic,
there is no vCont;s packet at all, and some range-stepping.exp tests
fail,
FAIL: gdb.base/range-stepping.exp: multi insns: next: vCont;s=1 vCont;r=1
This patch is to get rid of the checking to the number of vCont;s in
exec_cmd_expect_vCont_count.
gdb/testsuite:
2015-10-21 Yao Qi <yao.qi@linaro.org>
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Remove argument exp_vCont_s.
* gdb.base/range-stepping.exp: Callers updated.
* gdb.trace/range-stepping.exp: Likewise.
The existing logic was simply to flip syscall entry/return state when a
syscall trap was seen, and even then only with active 'catch syscall'.
That can get out of sync if 'catch syscall' is toggled at odd times.
This patch updates the entry/return state for all syscall traps,
regardless of catching state, and also updates known syscall state for
other kinds of traps. Almost all PTRACE_EVENT stops are delivered from
the middle of a syscall, so this can act like an entry. Every other
kind of ptrace stop is only delivered outside of syscall event pairs, so
marking them ignored ensures the next syscall trap looks like an entry.
Three new test scenarios are added to catch-syscall.exp:
- Disable 'catch syscall' from an entry to deliberately miss the return
event, then re-enable to make sure a new entry is recognized.
- Enable 'catch syscall' for the first time from a vfork event, which is
a PTRACE_EVENT_VFORK in the middle of the syscall. Make sure the next
syscall event is recognized as the return.
- Make sure entry and return are recognized for an ENOSYS syscall. This
is to defeat a common x86 hack that uses the pre-filled ENOSYS return
value as a sign of being on the entry side.
gdb/ChangeLog:
2015-10-19 Josh Stone <jistone@redhat.com>
* linux-nat.c (linux_handle_syscall_trap): Always update entry/
return state, even when not actively catching syscalls at all.
(linux_handle_extended_wait): Mark syscall_state like an entry.
(wait_lwp): Set syscall_state ignored for other traps.
(linux_nat_filter_event): Likewise.
gdb/testsuite/ChangeLog:
2015-10-19 Josh Stone <jistone@redhat.com>
* gdb.base/catch-syscall.c: Include <sched.h>.
(unknown_syscall): New variable.
(main): Trigger a vfork and an unknown syscall.
* gdb.base/catch-syscall.exp (vfork_syscalls): New variable.
(unknown_syscall_number): Likewise.
(check_call_to_syscall): Accept an optional syscall pattern.
(check_return_from_syscall): Likewise.
(check_continue): Likewise.
(test_catch_syscall_without_args): Check for vfork and ENOSYS.
(test_catch_syscall_skipping_return): New test toggling off 'catch
syscall' to step over the syscall return, then toggling back on.
(test_catch_syscall_mid_vfork): New test turning on 'catch syscall'
during a PTRACE_EVENT_VFORK stop, in the middle of a vfork syscall.
(do_syscall_tests): Call test_catch_syscall_without_args and
test_catch_syscall_mid_vfork.
(test_catch_syscall_without_args_noxml): Check for vfork and ENOSYS.
(fill_all_syscalls_numbers): Initialize unknown_syscall_number.
The func command, available when starting gdb in dbx mode, is supposed
to take a function name and locate the frame for that function in the
stack. This has been broken for a while due to an invalid check of the
arguments within the worker function. Fixed in this commit.
gdb/ChangeLog:
* stack.c (func_command): Return early when there is no ARG
string.
gdb/testsuite/ChangeLog:
* gdb.base/dbx.exp (test_func): Remove xfails, update expected
results.
Assume foo_array is a pointer to a C structure. GDB must evaluate the
following expression properly, but it does not currently:
(gdb) print 1 && &foo_array[1].a
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_STRUCT operation. As a consequence, the rest of
the code believes that one cannot take the address of the returned
value.
This patch fixes STRUCTOP_STRUCT handling so that the VALUE_LVAL
attribute for the returned value is properly initialized. After this
change, the above session becomes:
(gdb) print 1 && &foo_array[1].a
$1 = 1
gdb/ChangeLog:
* eval.c (evaluate_subexp_standard) <STRUCTOP_STRUCT>: If
EVAL_AVOID_SIDE_EFFECTS mode, forward the VALUE_LVAL attribute
to the returned value.
gdb/testsuite/ChangeLog:
* gdb.base/nested-addr.c: New file.
* gdb.base/nested-addr.exp: New testcase.
Tested on x86_64-linux, no regression.
This patch fixes this racy failure, with the native-extended-gdbserver
board:
(gdb) run
Starting program: build/gdb/testsuite/outputs/gdb.base/a2-run/a2-run
Remote debugging from host 127.0.0.1
Process build/gdb/testsuite/outputs/gdb.base/a2-run/a2-run created; pid = 23832
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading /lib64/libm.so.6 from remote target...
Reading /lib64/libc.so.6 from remote target...
[Inferior 1 (process 23832) exited with code 01]
(gdb) FAIL: gdb.base/a2-run.exp: run "a2-run" with no args
PASS: gdb.base/a2-run.exp: no spurious messages at program exit
run 5
Starting program: build/gdb/testsuite/outputs/gdb.base/a2-run/a2-run 5
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
usage: factorial <number>
Child exited with status 1
Note that the output is correct; it's just that inferior output
appeared after gdb's output, and the test doesn't handle that
correctly.
This comment isn't really correct, unfortunately:
# waiting. If we had already seen the status wrapper exit,
# gdb_test_multiple/expect has no spawn ids left, and thus
# returns.
That's true of expect in general, but I had missed / forgot that
gdb_test_multiple internally has extra matches using "-i
$gdb_spawn_id", so even if the caller clears all the indirect spawn id
lists, gdb_test_multiple will continue waiting.
So do a conditional exp_continue manually instead.
gdb/testsuite/ChangeLog:
2015-10-09 Pedro Alves <palves@redhat.com>
* gdb.base/a2-run.exp (maybe_exp_continue): New procedure.
(top level): Use it in the run with no args test.
clang names the local variable t_structs_a.buf.
gdb/testsuite/ChangeLog:
* gdb.base/callfuncs.exp (do_function_calls): Handle clang naming
of function static local variable.
This patch, relative to a tree with
https://sourceware.org/ml/gdb-patches/2015-08/msg00295.html, fixes
issues/crashes that trigger if something unexpected happens during a
hook-stop.
E.g., if the inferior disappears while running the hook-stop, we hit
failed assertions:
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>kill
>end
(gdb) si
Kill the program being debugged? (y or n) [answered Y; input not from terminal]
/home/pedro/gdb/mygit/build/../src/gdb/thread.c:88: internal-error: inferior_thread: Assertion `tp' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
I noticed that if a hook-stop issues a synchronous execution command,
we print the same stop event twice:
(gdb) define hook-stop
Type commands for definition of "hook-stop".
End with a line saying just "end".
>si
>end
(gdb) si
0x000000000040074a 42 args[i] = 1; /* Init value. */ <<<<<<< once
0x000000000040074a 42 args[i] = 1; /* Init value. */ <<<<<<< twice
(gdb)
In MI:
*stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
*stopped,reason="end-stepping-range",frame={addr="0x000000000040074a",func="main",args=[],file="threads.c",fullname="/home/pedro/gdb/tests/threads.c",line="42"},thread-id="1",stopped-threads="all",core="0"
(gdb)
The fix has GDB stop processing the event if the context changed. I
don't expect people to be doing crazy things from the hook-stop.
E.g., it gives me headaches to try to come up a proper behavior for
handling a thread change from a hook-stop... (E.g., imagine the
hook-stop does thread N; step, with scheduler-locing on). I think the
most important bit here is preventing crashes.
The patch adds a new hook-stop.exp test that covers the above and also
merges in the old hook-stop-continue.exp and hook-stop-frame.exp into
the same framework.
gdb/ChangeLog:
2015-09-14 Pedro Alves <palves@redhat.com>
* infrun.c (current_stop_id): New global.
(get_stop_id, new_stop_id): New functions.
(fetch_inferior_event): Handle normal_stop proceeding the target.
(struct stop_context): New.
(save_stop_context, release_stop_context_cleanup)
(stop_context_changed): New functions.
(normal_stop): Return true if the hook-stop changes the stop
context.
* infrun.h (get_stop_id): Declare.
(normal_stop): Now returns int. Add documentation.
gdb/testsuite/ChangeLog:
2015-09-14 Pedro Alves <palves@redhat.com>
* gdb.base/hook-stop-continue.c: Delete.
* gdb.base/hook-stop-continue.exp: Delete.
* gdb.base/hook-stop-frame.c: Delete.
* gdb.base/hook-stop-frame.exp: Delete.
* gdb.base/hook-stop.c: New file.
* gdb.base/hook-stop.exp: New file.
This patch updates several exec-related tests and some of the library
functions in order to get them running with extended-remote. There were
three changes that were required, as follows:
In gdb.base/foll-exec.exp, use 'clean_start' in place of proc 'zap_session'
to reset the state of the debugger between tests. This sets 'remote
exec-file' to execute the correct binary file in each subsequent test.
In gdb.base/pie-execl.exp, there is an expect statement with an expression
that is used to match output from both gdb and the program under debug.
For the remote target, this had to be split into two expressions, using
$inferior_spawn_id to match the output from the program.
Because I had encountered problems with extended-remote exec events in
non-stop mode in my manual testing, I added non-stop testing to the
non-ldr-exc-[1234].exp tests. In order to set non-stop mode for remote
targets, it is necessary to 'set non-stop on' after gdb has started, but
before it connects to gdbserver. This is done using 'save_vars' to set
non-stop mode in GDBFLAGS, so GDB sets non-stop mode on startup.
gdb/testsuite/ChangeLog:
* gdb.base/foll-exec.c: Add copyright header. Fix
formatting issues.
* gdb.base/foll-exec.exp (zap_session): Delete proc.
(do_exec_tests): Use clean_restart in place of zap_session,
and for test initialization. Fix formatting issues. Use
fail in place of perror.
* gdb.base/pie-execl.exp (main): Use 'inferior_spawn_id' in
an expect statement to match an expression with output from
the program under debug.
* gdb.threads/non-ldr-exc-1.exp (do_test, main): Add
non-stop tests and pass stop mode argument to clean_restart.
Use save_vars to enable non-stop in GDBFLAGS.
* gdb.threads/non-ldr-exc-2.exp: Likewise.
* gdb.threads/non-ldr-exc-3.exp: Likewise.
* gdb.threads/non-ldr-exc-4.exp: Likewise.
We currently set attach_flag when attaching to a process, so we should
make sure to unset it when forking a new process. Otherwise attach_flag
would remain set after forking, if the previous process associated with
the inferior was attached to.
gdb/ChangeLog:
* target.c (target_pre_inferior): Unset attach_flag.
gdb/testsuite/ChangeLog:
* gdb.base/run-after-attach.exp: New test file.
* gdb.base/run-after-attach.c: New test file.
This patch implements a new GDB test for follow-exec-mode. Although
there is a GDB test for debugging across an exec, there is no test for
follow-exec-mode. This test is derived from gdb.base/foll-exec.exp,
and re-uses execd-prog.c as the program to exec.
The following behavior is tested:
follow-exec-mode == "same"
- 'next' over the exec, check for one inferior
- 'continue' past the exec to a breakpoint, check for one inferior
- after the exec, use a 'run' command to run the current binary
follow-exec-mode == "new"
- 'next' over the exec, check for two inferiors
- 'continue' past the exec to a breakpoint, check for two inferiors
- after the exec, use a 'run' command to run the current binary
- after the exec, use the 'inferior' command to switch inferiors,
then use a 'run' command to run the current binary
Note that single-step breakpoints do not survive across an exec.
There has to be a breakpoint in the execed program in order for
it to stop right after the exec.
gdb/testsuite/ChangeLog:
* gdb.base/foll-exec-2.c: New test program.
* gdb.base/foll-exec-2.exp: New test.
GDB's current behavior when dealing with non-local references in the
context of nested fuctions is approximative:
- code using valops.c:value_of_variable read the first available stack
frame that holds the corresponding variable (whereas there can be
multiple candidates for this);
- code directly relying on read_var_value will instead read non-local
variables in frames where they are not even defined.
This change adds the necessary context to symbol reads (to get the block
they belong to) and to blocks (the static link property, if any) so that
GDB can make the proper decisions when dealing with non-local varibale
references.
gdb/ChangeLog:
* ada-lang.c (ada_read_var_value): Add a var_block argument
and pass it to default_read_var_value.
* block.c (block_static_link): New accessor.
* block.h (block_static_link): Declare it.
* buildsym.c (finish_block_internal): Add a static_link
argument. If there is a static link, associate it to the new
block.
(finish_block): Add a static link argument and pass it to
finish_block_internal.
(end_symtab_get_static_block): Update calls to finish_block and
to finish_block_internal.
(end_symtab_with_blockvector): Update call to
finish_block_internal.
* buildsym.h: Forward-declare struct dynamic_prop.
(struct context_stack): Add a static_link field.
(finish_block): Add a static link argument.
* c-exp.y: Remove an obsolete comment (evaluation of variables
already start from the selected frame, and now they climb *up*
the call stack) and propagate the block information to the
produced expression.
* d-exp.y: Likewise.
* f-exp.y: Likewise.
* go-exp.y: Likewise.
* jv-exp.y: Likewise.
* m2-exp.y: Likewise.
* p-exp.y: Likewise.
* coffread.c (coff_symtab_read): Update calls to finish_block.
* dbxread.c (process_one_symbol): Likewise.
* xcoffread.c (read_xcoff_symtab): Likewise.
* compile/compile-c-symbols.c (convert_one_symbol): Promote the
"sym" parameter to struct block_symbol, update its uses and pass
its block to calls to read_var_value.
(convert_symbol_sym): Update the calls to convert_one_symbol.
* compile/compile-loc2c.c (do_compile_dwarf_expr_to_c): Update
call to read_var_value.
* dwarf2loc.c (block_op_get_frame_base): New.
(dwarf2_block_frame_base_locexpr_funcs): Implement the
get_frame_base method.
(dwarf2_block_frame_base_loclist_funcs): Likewise.
(dwarf2locexpr_baton_eval): Add a frame argument and use it
instead of the selected frame in order to evaluate the
expression.
(dwarf2_evaluate_property): Add a frame argument. Update call
to dwarf2_locexpr_baton_eval to provide a frame in available and
to handle the absence of address stack.
* dwarf2loc.h (dwarf2_evaluate_property): Add a frame argument.
* dwarf2read.c (attr_to_dynamic_prop): Add a forward
declaration.
(read_func_scope): Record any available static link description.
Update call to finish_block.
(read_lexical_block_scope): Update call to finish_block.
* findvar.c (follow_static_link): New.
(get_hosting_frame): New.
(default_read_var_value): Add a var_block argument. Use
get_hosting_frame to handle non-local references.
(read_var_value): Add a var_block argument and pass it to the
LA_READ_VAR_VALUE method.
* gdbtypes.c (resolve_dynamic_range): Update calls to
dwarf2_evaluate_property.
(resolve_dynamic_type_internal): Likewise.
* guile/scm-frame.c (gdbscm_frame_read_var): Update call to
read_var_value, passing it the block coming from symbol lookup.
* guile/scm-symbol.c (gdbscm_symbol_value): Update call to
read_var_value (TODO).
* infcmd.c (finish_command_continuation): Update call to
read_var_value, passing it the block coming from symbol lookup.
* infrun.c (insert_exception_resume_breakpoint): Likewise.
* language.h (struct language_defn): Add a var_block argument to
the LA_READ_VAR_VALUE method.
* objfiles.c (struct static_link_htab_entry): New.
(static_link_htab_entry_hash): New.
(static_link_htab_entry_eq): New.
(objfile_register_static_link): New.
(objfile_lookup_static_link): New.
(free_objfile): Free the STATIC_LINKS hashed map if needed.
* objfiles.h: Include hashtab.h.
(struct objfile): Add a static_links field.
(objfile_register_static_link): New.
(objfile_lookup_static_link): New.
* printcmd.c (print_variable_and_value): Update call to
read_var_value.
* python/py-finishbreakpoint.c (bpfinishpy_init): Likewise.
* python/py-frame.c (frapy_read_var): Update call to
read_var_value, passing it the block coming from symbol lookup.
* python/py-framefilter.c (extract_sym): Add a sym_block
parameter and set the pointed value to NULL (TODO).
(enumerate_args): Update call to extract_sym.
(enumerate_locals): Update calls to extract_sym and to
read_var_value.
* python/py-symbol.c (sympy_value): Update call to
read_var_value (TODO).
* stack.c (read_frame_local): Update call to read_var_value.
(read_frame_arg): Likewise.
(return_command): Likewise.
* symtab.h (struct symbol_block_ops): Add a get_frame_base
method.
(struct symbol): Add a block field.
(SYMBOL_BLOCK): New accessor.
* valops.c (value_of_variable): Remove frame/block handling and
pass the block argument to read_var_value, which does this job
now.
(value_struct_elt_for_reference): Update calls to
read_var_value.
(value_of_this): Pass the block found to read_var_value.
* value.h (read_var_value): Add a var_block argument.
(default_read_var_value): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/nested-subp1.exp: New file.
* gdb.base/nested-subp1.c: New file.
* gdb.base/nested-subp2.exp: New file.
* gdb.base/nested-subp2.c: New file.
* gdb.base/nested-subp3.exp: New file.
* gdb.base/nested-subp3.c: New file.
This avoids two more types of FAILs with the gnu_vector test case.
First, for POWER targets newer GCCs emit an ABI note when invoked with
"-mcpu=native". Then the test case fell back to non-native compile,
producing code for a non-vector ABI. But that is not supported by GDB.
Thus the compiler note is now suppressed with "-Wno-psabi".
Second, on s390 the test case produced FAILs after falling back to a
non-vector ABI when using "finish" or "return" in a vector-valued
function. This was due to a long-standing known bug (Bug 8549). This
case is now detected, and KFAILs are emitted instead.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.exp: Try compilation with "-mcpu=native
-Wno-psabi" if "-mcpu=native" fails. For the tests with "finish"
and "return" use KFAIL when GDB can not read/write the vector
return value.
Invoking either of the above commands on an inferior that's not running
triggers the following assert failure:
.../binutils-gdb/gdb/thread.c:514: internal-error: any_thread_of_process: Assertion `pid != 0' failed.
The fix is straightforward. This patch also adds a test to check the
basic functionality of these commands, along with testing this fix in
particular. Tested on x86_64 Linux.
gdb/ChangeLog:
* inferior.c (detach_inferior_command): Don't call
any_thread_of_process when pid is 0.
(kill_inferior_command): Likewise.
gdb/testsuite/ChangeLog:
* gdb.base/kill-detach-inferiors-cmd.exp: New test file.
* gdb.base/kill-detach-inferiors-cmd.c: New test file.
The "source centric" /m option to the disassemble command is often
unhelpful, e.g., in the presence of optimized code.
This patch adds a /s modifier that is better.
For one, /m only prints instructions from the originating source file,
leaving out instructions from e.g., inlined functions from other files.
gdb/ChangeLog:
PR gdb/11833
* NEWS: Document new /s modifier for the disassemble command.
* cli/cli-cmds.c (disassemble_command): Add support for /s.
(_initialize_cli_cmds): Update online docs of disassemble command.
* disasm.c: #include "source.h".
(struct deprecated_dis_line_entry): Renamed from dis_line_entry.
All uses updated.
(dis_line_entry): New struct.
(hash_dis_line_entry, eq_dis_line_entry): New functions.
(allocate_dis_line_table): New functions.
(maybe_add_dis_line_entry, line_has_code_p): New functions.
(dump_insns): New arg end_pc. All callers updated.
(do_mixed_source_and_assembly_deprecated): Renamed from
do_mixed_source_and_assembly. All callers updated.
(do_mixed_source_and_assembly): New function.
(gdb_disassembly): Handle /s (DISASSEMBLY_SOURCE).
* disasm.h (DISASSEMBLY_SOURCE_DEPRECATED): Renamed from
DISASSEMBLY_SOURCE. All uses updated.
(DISASSEMBLY_SOURCE): New macro.
* mi/mi-cmd-disas.c (mi_cmd_disassemble): New modes 4,5.
gdb/doc/ChangeLog:
* gdb.texinfo (Machine Code): Update docs for mixed source/assembly
disassembly.
(GDB/MI Data Manipulation): Update docs for new disassembly modes.
gdb/testsuite/ChangeLog:
* gdb.mi/mi-disassemble.exp: Update.
* gdb.base/disasm-optim.S: New file.
* gdb.base/disasm-optim.c: New file.
* gdb.base/disasm-optim.h: New file.
* gdb.base/disasm-optim.exp: New file.
Keith reported that gdb.base/dso2dso.exp is broken, with the following
error:
| $ make check RUNTESTFLAGS=dso2dso.exp
| [snip]
| Running ../../../src/gdb/testsuite/gdb.base/dso2dso.exp ...
| ERROR: tcl error sourcing ../../../src/gdb/testsuite/gdb.base/dso2dso.exp.
| ERROR: couldn't open
| "../../../src/gdb/testsuite/gdb.base/../../../src/gdb/testsuite/gdb.base/dso2dso-dso1.c":
| no such file or directory
| while executing
| "error "$message""
| (procedure "gdb_get_line_number" line 14)
| invoked from within
| "gdb_get_line_number "STOP HERE" $srcfile_libdso1"
| (file "../../../src/gdb/testsuite/gdb.base/dso2dso.exp" line 60)
| invoked from within
| "source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
| ("uplevel" body line 1)
| invoked from within
| "uplevel #0 source ../../../src/gdb/testsuite/gdb.base/dso2dso.exp"
| invoked from within
| "catch "uplevel #0 source $test_file_name""
This happens because gdb_get_line_number will prepend $srcdir/$subdir
if the given filename does not start with "/", and this happens when
GDB was configured using a relative path to the configure script.
When using an absolute path like I do, we avoid the pre-pending that
Keith is seeing.
gdb/testsuite/ChangeLog:
Keith Seitz <keiths@redhat.com>:
* gdb.base/dso2dso.exp: Pass basename of source file in call
to gdb_get_line_number.
Tested on x86_64-linux with both scenarios.
Making all-stop run on top of non-stop caused a small regression
in behavior. This was observed on x86_64-linux. The attached testcase
is in C whereas the investigation was done with an Ada program,
but it's the same scenario, and using a C testcase allows wider testing.
Basically: I am debugging a single-threaded program, and currently
stopped inside a function provided by a shared-library, at a line
calling a subprogram provided by a second shared library, and trying
to "next" over that function call.
Before we changed the default all-stop behavior, we had:
7 Impl_Initialize; -- Stop here and try "next" over this line
(gdb) n
8 return 5; <<-- OK
But now, "next" just stops much earlier:
(gdb) n
0x00007ffff7bd8560 in impl.initialize@plt () from /[...]/lib/libpck.so
What happens is that next stops at a call instruction, which calls
the function's PLT, and GDB fails to notice that the inferior stepped
into a subroutine, and so decides that we're done. We can see another
symptom of the same issue by looking at the backtrace at the point
GDB stopped:
(gdb) bt
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00000000f7bd86f9 in ?? ()
#2 0x00007fffffffdf50 in ?? ()
#3 0x0000000000401893 in a () at /[...]/a.adb:7
Backtrace stopped: frame did not save the PC
With a functioning GDB, the backtrace looks like the following instead:
#0 0x00007ffff7bd8560 in impl.initialize@plt ()
from /[...]/lib/libpck.so
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7
#2 0x0000000000401893 in a () at /[...]/a.adb:7
Note how, for frame #1, the address looks quite similar, except
for the high-order bits not being set:
#1 0x00007ffff7bd86f9 in sub () at /[...]/pck.adb:7 <<<-- OK
#1 0x00000000f7bd86f9 in ?? () <<<-- WRONG
^^^^
||||
Wrong
Investigating this further led me to displaced stepping.
As we are "next"-ing from a location where a breakpoint is inserted,
we need to step out of it, and since we're on non-stop mode, we need
to do it using displaced stepping. And looking at
amd64-tdep.c:amd64_displaced_step_fixup, I found the code that handles
the return address:
regcache_cooked_read_unsigned (regs, AMD64_RSP_REGNUM, &rsp);
retaddr = read_memory_unsigned_integer (rsp, retaddr_len, byte_order);
retaddr = (retaddr - insn_offset) & 0xffffffffUL;
The mask used to compute retaddr looks wrong to me, keeping only
4 bytes instead of 8, and explains why the high order bits of
the backtrace are unset. What happens is that, after the displaced
stepping has completed, GDB restores that return address at the location
where the program expects it. But because the top half bits of
the address have been masked out, the return address is now invalid.
The incorrect behavior of the "next" command and the backtrace at
that location are the first symptoms of that. Another symptom is
that this actually alters the behavior of the program, where a "cont"
from there soon leads to a SEGV when the inferior tries to jump back
to that incorrect return address:
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x00000000f7bd86f9 in ?? ()
^^^^^^^^^^^^^^^^^^
This patch fixes the issue by using a mask that seems more appropriate
for this architecture.
gdb/ChangeLog:
* amd64-tdep.c (amd64_displaced_step_fixup): Fix the mask used to
compute RETADDR.
gdb/testsuite/ChangeLog:
* gdb.base/dso2dso-dso2.c, gdb.base/dso2dso-dso2.h,
gdb.base/dso2dso-dso1.c, gdb.base/dso2dso-dso1.h, gdb.base/dso2dso.c,
gdb.base/dso2dso.exp: New files.
Tested on x86_64-linux, no regression.
Keith found out that several tests were failing when testing the
native-gdbserver board on Fedora (x86_64). Strangely, these failures
had not been reported by our BuildBot. Later, he found that the reason
for this was because the failures only happened when running the
testsuite without FORCE_PARALLEL (i.e., on serial mode; maybe it would
be worth having a builder testing things on serial...). Then, he
decided to start bisecting the changes to see which one introduced the
failure (it was not trivial to know this only by looking at gdb.log).
After a lot of time, he found that Pedro's commit
e1316e60d4 was the culprit. There was
nothing wrong in the code, but the new gdb.base/checkpoint-ns.exp
testcase did something that left the GDBFLAGS variable in an
inconsistent state. This test works by modifying this variable to set
non-stop on, sourcing gdb.base/checkpoint.exp (which does the hard
work), and then restoring the old value on GDBFLAGS. However, this was
not working because gdb.base/checkpoint.exp bails out if it is being
tested on gdbserver, and when it calls "continue" the control goes back
to the function calling the tests, and not to
gdb.base/checkpoint-ns.exp.
The fix is simple: just wrap the "source" call, and make
gdb.base/checkpoint-ns.exp aware of the "continue"/"return" calls made
by gdb.base/checkpoint.exp.
gdb/testsuite/ChangeLog:
2015-08-12 Sergio Durigan Junior <sergiodj@redhat.com>
Pedro Alves <palves@redhat.com>
Keith Seitz <keiths@redhat.com>
* gdb.base/checkpoint-ns.exp: Use save_vars to save and restore
GDBFLAGS.
gdb/testsuite/ChangeLog:
* gdb.base/gdbhistsize-history.exp
(test_histsize_history_setting): Use save_vars.
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Use save_vars.
(test_no_truncation_of_unlimited_history_file): Use save_vars.
* gdb.base/readline.exp: Use save_vars.
This patch adds documentation for explicit locations to both the
User Manual and gdb's online help system.
gdb/ChangeLog:
* NEWS: Mention explicit locations.
* breakpoint.c [LOCATION_HELP_STRING]: New macro.
[BREAK_ARGS_HELP]: Use LOCATION_HELP_STRING.
(_initialize_breakpoint): Update documentation for
"clear", "break", "trace", "strace", "ftrace", and "dprintf".
gdb/doc/ChangeLog:
* gdb.texinfo (Thread-Specific Breakpoints, Printing Source Lines):
Use "location(s)"instead of "linespec(s)".
(Specifying a Location): Rewrite.
Add subsections describing linespec, address, and explicit locations.
Add node/menu for each subsection.
(Source and Machine Code, C Preprocessor Macros)
(Create and Delete Trace points)
(Extensions for Ada Tasks): Use "location(s)" instead of "linespec(s)".
(Continuing at a Different Address): Remove "linespec" examples.
Add reference to "Specify a Location"
(The -break-insert Command): Rewrite. Add anchor.
Add reference to appropriate manual section discussing locations.
(The -dprintf-insert Command): Refer to -break-insert for
specification of 'location'.
gdb/testsuite/ChangeLog:
* gdb.base/help.exp: Update help_breakpoint_text.
This patch converts the code base to use the new struct event_location
API being introduced. This patch preserves the current functionality and
adds no new features.
The "big picture" API usage introduced by this patch may be illustrated
with a simple exmaple. Where previously developers would write:
void
my_command (char *arg, int from_tty)
{
create_breakpoint (..., arg, ...);
...
}
one now uses:
void
my_command (char *arg, int from_tty)
{
struct event_locaiton *location;
struct cleanup *back_to;
location = string_to_event_locaiton (&arg, ...);
back_to = make_cleanup_delete_event_location (location);
create_breakpoint (..., location, ...);
do_cleanups (back_to);
}
Linespec-decoding functions (now called location-decoding) such as
decode_line_full no longer skip argument pointers over processed input.
That functionality has been moved into string_to_event_location as
demonstrated above.
gdb/ChangeLog
* ax-gdb.c: Include location.h.
(agent_command_1) Use linespec location instead of address
string.
* break-catch-throw.c: Include location.h.
(re_set_exception_catchpoint): Use linespec locations instead
of address strings.
* breakpoint.c: Include location.h.
(create_overlay_event_breakpoint, create_longjmp_master_breakpoint)
(create_std_terminate_master_breakpoint)
(create_exception_master_breakpoint, update_breakpoints_after_exec):
Use linespec location instead of address string.
(print_breakpoint_location): Use locations and
event_location_to_string.
Print extra_string for pending locations for non-MI streams.
(print_one_breakpoint_location): Use locations and
event_location_to_string.
(init_raw_breakpoint_without_location): Initialize b->location.
(create_thread_event_breakpoint): Use linespec location instead of
address string.
(init_breakpoint_sal): Likewise.
Only save extra_string if it is non-NULL and not the empty string.
Use event_location_to_string instead of `addr_string'.
Constify `p' and `endp'.
Use skip_spaces_const/skip_space_const instead of non-const versions.
Copy the location into the breakpoint.
If LOCATION is NULL, save the breakpoint address as a linespec location
instead of an address string.
(create_breakpoint_sal): Change `addr_string' parameter to a struct
event_location. All uses updated.
(create_breakpoints_sal): Likewise for local variable `addr_string'.
(parse_breakpoint_sals): Use locations instead of address strings.
Remove check for empty linespec with conditional.
Refactor.
(decode_static_tracepoint_spec): Make argument const and update
function.
(create_breakpoint): Change `arg' to a struct event_location and
rename.
Remove `copy_arg' and `addr_start'.
If EXTRA_STRING is empty, set it to NULL.
Don't populate `canonical' for pending breakpoints.
Pass `extra_string' to find_condition_and_thread.
Clear `extra_string' if `rest' was NULL.
Do not error with "garbage after location" if setting a dprintf
breakpoint.
Copy the location into the breakpoint instead of an address string.
(break_command_1): Use string_to_event_location and pass this to
create_breakpoint instead of an address string.
Check against `arg_cp' for a probe linespec.
(dprintf_command): Use string_to_event_location and pass this to
create_breakpoint instead of an address string.
Throw an exception if no format string was specified.
(print_recreate_ranged_breakpoint): Use event_location_to_string
instead of address strings.
(break_range_command, until_break_command)
(init_ada_exception_breakpoint): Use locations instead
of address strings.
(say_where): Print out extra_string for pending locations.
(base_breakpoint_dtor): Delete `location' and `location_range_end' of
the breakpoint.
(base_breakpoint_create_sals_from_location): Use struct event_location
instead of address string.
Remove `addr_start' and `copy_arg' parameters.
(base_breakpoint_decode_location): Use struct event_location instead of
address string.
(bkpt_re_set): Use locations instead of address strings.
Use event_location_empty_p to check for unset location.
(bkpt_print_recreate): Use event_location_to_string instead of
an address string.
Print out extra_string for pending locations.
(bkpt_create_sals_from_location, bkpt_decode_location)
(bkpt_probe_create_sals_from_location): Use struct event_location
instead of address string.
(bkpt_probe_decode_location): Use struct event_location instead of
address string.
(tracepoint_print_recreate): Use event_location_to_string to
recreate the tracepoint.
(tracepoint_create_sals_from_location, tracepoint_decode_location)
(tracepoint_probe_create_sals_from_location)
(tracepoint_probe_decode_location): Use struct event_location
instead of address string.
(dprintf_print_recreate): Use event_location_to_string to recreate
the dprintf.
(dprintf_re_set): Remove check for valid/missing format string.
(strace_marker_create_sals_from_location)
(strace_marker_create_breakpoints_sal, strace_marker_decode_location)
(update_static_tracepoint): Use struct event_location instead of
address string.
(location_to_sals): Likewise.
Pass `extra_string' to find_condition_and_thread.
For newly resolved pending breakpoint locations, clear the location's
string representation.
Assert that the breakpoint's condition string is NULL when
condition_not_parsed.
(breakpoint_re_set_default, create_sals_from_location_default)
(decode_location_default, trace_command, ftrace_command)
(strace_command, create_tracepoint_from_upload): Use locations
instead of address strings.
* breakpoint.h (struct breakpoint_ops) <create_sals_from_location>:
Use struct event_location instead of address string.
Update all uses.
<decode_location>: Likewise.
(struct breakpoint) <addr_string>: Change to struct event_location
and rename `location'.
<addr_string_range_end>: Change to struct event_location and rename
`location_range_end'.
(create_breakpoint): Use struct event_location instead of address
string.
* cli/cli-cmds.c: Include location.h.
(edit_command, list_command): Use locations instead of address strings.
* elfread.c: Include location.h.
(elf_gnu_ifunc_resolver_return_stop): Use event_location_to_string.
* guile/scm-breakpoint.c: Include location.h.
(bpscm_print_breakpoint_smob): Use event_location_to_string.
(gdbscm_register_breakpoint): Use locations instead of address
strings.
* linespec.c: Include location.h.
(struct ls_parser) <stream>: Change to const char *.
(PARSER_STREAM): Update.
(lionespec_lexer_lex_keyword): According to find_condition_and_thread,
keywords must be followed by whitespace.
(canonicalize_linespec): Save a linespec location into `canonical'.
Save a canonical linespec into `canonical'.
(parse_linespec): Change `argptr' to const char * and rename `arg'.
All uses updated.
Update function description.
(linespec_parser_new): Initialize `parser'.
Update initialization of parsing stream.
(event_location_to_sals): New function.
(decode_line_full): Change `argptr' to a struct event_location and
rename it `location'.
Use locations instead of address strings.
Call event_location_to_sals instead of parse_linespec.
(decode_line_1): Likewise.
(decode_line_with_current_source, decode_line_with_last_displayed)
Use locations instead of address strings.
(decode_objc): Likewise.
Change `argptr' to const char * and rename `arg'.
(destroy_linespec_result): Delete the linespec result's location
instead of freeing the address string.
* linespec.h (struct linespec_result) <addr_string>: Change to
struct event_location and rename to ...
<location>: ... this.
(decode_line_1, decode_line_full): Change `argptr' to struct
event_location. All callers updated.
* mi/mi-cmd-break.c: Include language.h, location.h, and linespec.h.
(mi_cmd_break_insert_1): Use locations instead of address strings.
Throw an error if there was "garbage" at the end of the specified
linespec.
* probe.c: Include location.h.
(parse_probes): Change `argptr' to struct event_location.
Use event locations instead of address strings.
* probe.h (parse_probes): Change `argptr' to struct event_location.
* python/py-breakpoint.c: Include location.h.
(bppy_get_location): Constify local variable `str'.
Use event_location_to_string.
(bppy_init): Use locations instead of address strings.
* python/py-finishbreakpoint.c: Include location.h.
(bpfinishpy_init): Remove local variable `addr_str'.
Use locations instead of address strings.
* python/python.c: Include location.h.
(gdbpy_decode_line): Use locations instead of address strings.
* remote.c: Include location.h.
(remote_download_tracepoint): Use locations instead of address
strings.
* spu-tdep.c: Include location.h.
(spu_catch_start): Remove local variable `buf'.
Use locations instead of address strings.
* tracepoint.c: Include location.h.
(scope_info): Use locations instead of address strings.
(encode_source_string): Constify parameter `src'.
* tracepoint.h (encode_source_string): Likewise.
gdb/testsuite/ChangeLog
* gdb.base/dprintf-pending.exp: Update dprintf "without format"
test.
Add tests for missing ",FMT" and ",".
gdb/ChangeLog:
* symtab.c (make_file_symbol_completion_list_1): Renamed from
make_file_symbol_completion_list and made static.
(make_file_symbol_completion_list): New function.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add location completer tests.
Running the testsuite with "maint set target-non-stop on" shows:
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #98 (false warning)
continue
Continuing.
dl_main (phdr=<optimized out>..., auxv=<optimized out>) at rtld.c:2302
2302 LIBC_PROBE (init_complete, 2, LM_ID_BASE, r);
Cannot access memory at address 0x400532
(gdb) PASS: gdb.base/valgrind-infcall.exp: continue #99 (false warning)
p gdb_test_infcall ()
$1 = 1
(gdb) FAIL: gdb.base/valgrind-infcall.exp: p gdb_test_infcall ()
Even though that was a native GNU/Linux test run, this test spawns
Valgrind and connects to it with "target remote". The error above is
actually orthogonal to target-non-stop. The real issue is that that
enables displaced stepping, and displaced stepping doesn't work with
Valgrind, because we can't write to the inferior memory (thus can't
copy the instruction to the scratch pad area).
I'm sure there will be other targets with the same issue, so trying to
identify Valgrind wouldn't be sufficient. The fix is to try setting
up the displaced step anyway. If we get a MEMORY_ERROR, we disable
displaced stepping for that inferior, and fall back to doing an
in-line step-over. If "set displaced-stepping" is "on" (as opposed to
"auto), GDB warns displaced stepping failed ("on" is mainly useful for
the testsuite, not for users).
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* inferior.h (struct inferior) <displaced_stepping_failed>: New
field.
* infrun.c (use_displaced_stepping_now_p): New parameter 'inf'.
Return false if dispaced stepping failed before.
(resume): Pass the current inferior to
use_displaced_stepping_now_p. Wrap displaced_step_prepare in
TRY/CATCH. If we get a MEMORY_ERROR, set the inferior's
displaced_stepping_failed flag, and fall back to an in-line
step-over.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.base/valgrind-disp-step.c: New file.
* gdb.base/valgrind-disp-step.exp: New file.
Letting a "checkpoint" run to exit with "set non-stop on" behaves
differently compared to the default all-stop mode ("set non-stop
off").
Currently, in non-stop mode:
(gdb) start
Temporary breakpoint 1 at 0x40086b: file src/gdb/testsuite/gdb.base/checkpoint.c, line 28.
Starting program: build/gdb/testsuite/gdb.base/checkpoint
Temporary breakpoint 1, main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
28 char *tmp = &linebuf[0];
(gdb) checkpoint
checkpoint 1: fork returned pid 24948.
(gdb) c
Continuing.
Copy complete.
Deleting copy.
[Inferior 1 (process 24944) exited normally]
[Switching to process 24948]
(gdb) info threads
Id Target Id Frame
1 process 24948 "checkpoint" (running)
No selected thread. See `help thread'.
(gdb) c
The program is not being run.
(gdb)
Two issues above:
1. Thread 1 got stuck in "(running)" state (it isn't really running)
2. While checkpoints try to preserve the illusion that the thread is
still the same when the process exits, GDB switched to "No thread
selected." instead of staying with thread 1 selected.
Problem #1 is caused by handle_inferior_event and normal_stop not
considering that when a
TARGET_WAITKIND_SIGNALLED/TARGET_WAITKIND_EXITED event is reported,
and the inferior is mourned, the target may still have execution.
Problem #2 is caused by the make_cleanup_restore_current_thread
cleanup installed by fetch_inferior_event not being able to find the
original thread 1's ptid in the thread list, thus not being able to
restore thread 1 as selected thread. The fix is to make the cleanup
installed by make_cleanup_restore_current_thread aware of thread ptid
changes, by installing a thread_ptid_changed observer that adjusts the
cleanup's data.
After the patch, we get the same in all-stop and non-stop modes:
(gdb) c
Continuing.
Copy complete.
Deleting copy.
[Inferior 1 (process 25109) exited normally]
[Switching to process 25113]
(gdb) info threads
Id Target Id Frame
* 1 process 25113 "checkpoint" main () at src/gdb/testsuite/gdb.base/checkpoint.c:28
(gdb)
Turns out the whole checkpoints.exp file can run in non-stop mode
unmodified. I thought of moving most of the test file's contents to a
procedure that can be called twice, once in non-stop mode and another
in all-stop mode. But then, the test already takes close to 30
seconds to run on my machine, so I thought it'd be nicer to run
all-stop and non-stop mode in parallel. Thus I added a new
checkpoint-ns.exp file that just appends "set non-stop on" to GDBFLAGS
and sources checkpoint.exp.
gdb/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_inferior_event): If we get
TARGET_WAITKIND_SIGNALLED or TARGET_WAITKIND_EXITED in non-stop
mode, mark all threads of the exiting process as not-executing.
(normal_stop): If we get TARGET_WAITKIND_SIGNALLED or
TARGET_WAITKIND_EXITED in non-stop mode, finish all threads of the
exiting process, if inferior_ptid still points at a process.
* thread.c (struct current_thread_cleanup) <next>: New field.
(current_thread_cleanup_chain): New global.
(restore_current_thread_ptid_changed): New function.
(restore_current_thread_cleanup_dtor): Remove the cleanup from the
current_thread_cleanup_chain list.
(make_cleanup_restore_current_thread): Add the cleanup data to the
current_thread_cleanup_chain list.
(_initialize_thread): Install restore_current_thread_ptid_changed
as thread_ptid_changed observer.
gdb/testsuite/ChangeLog:
2015-08-07 Pedro Alves <palves@redhat.com>
* gdb.base/checkpoint-ns.exp: New file.
* gdb.base/checkpoint.exp: Pass explicit "checkpoint.c" to
standard_testfile.
This test fails with --target_board=native-extended-gdbserver because
it misses the usual "disconnect":
(gdb) target remote | /usr/lib64/valgrind/../../bin/vgdb --pid=30454
Already connected to a remote target. Disconnect? (y or n) n
Still connected.
(gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb (got interactive prompt)
gdb/testsuite/ChangeLog:
2015-08-06 Pedro Alves <palves@redhat.com>
* gdb.base/valgrind-infcall.exp: Issue a "disconnect".
2015-08-03 Sandra Loosemore <sandra@codesourcery.com>
gdb/testsuite/
* gdb.base/bp-permanent.exp: Report test as unsupported if
the target cannot stop at the permanent breakpoint.
The buildbots show that attach-many-short-lived-thread.exp is racy.
But after staring at debug logs and playing with SystemTap scripts for
a (long) while, I figured out that neither GDB, nor the kernel nor the
test's program itself are at fault.
The problem is simply that the testsuite machinery is currently
subject to PID-reuse races. The attach-many-short-lived-threads.c
test program just happens to be much more susceptible to trigger this
race because threads and processes share the same number space on
Linux, and the test spawns many many short lived threads in
succession, thus enlarging the race window a lot.
Part of the problem is that several tests spawn processes with "exec&"
(in order to test the "attach" command) , and then at the end of the
test, to make sure things are cleaned up, issue a 'remote_spawn "kill
-p $testpid"'. Since with tcl's "exec&", tcl itself is responsible
for reaping the process's exit status, when we go kill the process,
testpid may have already exited _and_ its status may have (and often
has) been reaped already. Thus it can happen that another process
meanwhile reuses $testpid, and that "kill" command kills the wrong
process... Frequently, that happens to be
attach-many-short-lived-thread, but this explains other test's races
as well.
In the attach-many-short-lived-threads test, it sometimes manifests
like this:
(gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads
Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads...done.
(gdb) Loaded /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads into /home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb
attach 5940
Attaching to program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads, process 5940
warning: process 5940 is a zombie - the process has already terminated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ptrace: Operation not permitted.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach
info threads
No threads.
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads
set breakpoint always-inserted on
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on
Other times the process dies while the test is ongoing (the process is
ptrace-stopped):
(gdb) print again = 1
Cannot access memory at address 0x6020cc
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior
(Recall that on Linux, SIGKILL is not interceptable)
And other times it dies just while we're detaching:
$4 = 319
(gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left
detach
Can't detach Thread 0x7fb13b7de700 (LWP 1842): No such process
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach
GDB mishandles the latter (it should ignore ESRCH while detaching just
like when continuing), but that's another story.
The fix here is to change spawn_wait_for_attach to use Expect's
'spawn' command instead of Tcl's 'exec&' to spawn programs, because
with spawn we control when to wait for/reap the process. That allows
killing the process by PID without being subject to pid-reuse races,
because even if the process is already dead, the kernel won't reuse
the process's PID until the zombie is reaped.
The other part of the problem lies in DejaGnu itself, unfortunately.
I have occasionally seen tests (attach-many-short-lived-threads
included, but not only that one) die with a random inexplicable
SIGTERM too, and that too is caused by the same reason, except that in
that case, the rogue SIGTERM is sent from this bit in DejaGnu's remote.exp:
exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $pid) &"
...
catch "wait -i $shell_id"
Even if the program exits promptly, that whole cascade of kills
carries on in the background, thus potentially killing the poor
process that manages to reuse $pid...
I sent a fix for that to the DejaGnu list:
http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html
With both patches in place, I haven't seen
attach-many-short-lived-threads.exp fail again.
Tested on x86_64 Fedora 20, native, gdbserver and extended-gdbserver.
gdb/testsuite/ChangeLog:
2015-07-31 Pedro Alves <palves@redhat.com>
* gdb.base/attach-pie-misread.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* gdb.base/attach-pie-noexec.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/attach-twice.exp: Likewise.
* gdb.base/attach.exp: Likewise.
(do_command_attach_tests): Use gdb_spawn_with_cmdline_opts and
gdb_test_multiple.
* gdb.base/solib-overlap.exp: Adjust to spawn_wait_for_attach
returning a spawn id instead of a pid. Use spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/valgrind-infcall.exp: Likewise.
* gdb.multi/multi-attach.exp: Likewise.
* gdb.python/py-prompt.exp: Likewise.
* gdb.python/py-sync-interp.exp: Likewise.
* gdb.server/ext-attach.exp: Likewise.
* gdb.threads/attach-into-signal.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.threads/attach-many-short-lived-threads.exp: Adjust to
spawn_wait_for_attach returning a spawn id instead of a pid. Use
spawn_id_get_pid and kill_wait_spawned_process.
* gdb.threads/attach-stopped.exp (corefunc): Use
spawn_wait_for_attach, spawn_id_get_pid and
kill_wait_spawned_process.
* gdb.base/break-interp.exp: Rename $res to $test_spawn_id.
Use spawn_id_get_pid. Wait for spawn id after eof. Use
kill_wait_spawned_process instead of explicit "kill -9".
* lib/gdb.exp (can_spawn_for_attach): Adjust comment.
(kill_wait_spawned_process, spawn_id_get_pid): New procedures.
(spawn_wait_for_attach): Use spawn instead of exec to spawn
processes. Don't map cygwin/windows pids here. Now returns a
spawn id list.
Just a slight cleanup. Committed as obvious.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp
(test_terminal_settings_preserved_after_cli_exit): Use
send_quit_command.
Tested on x86_64 Debian Stretch, native, gdbserver and
extended-gdbserver. Also tested that the various error paths, like if
$PPID is empty or if SIGTERM did not not kill GDB, function correctly.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp (send_quit_command):
New proc.
(test_terminal_settings_preserved_after_sigterm): New test.
Now that we can expect inferior output with the gdbserver boards, this
is all it takes to have the test pass against extended-remote
gdbserver.
Don Breazeal originally wrong something like this:
https://sourceware.org/ml/gdb-patches/2015-03/msg00506.html
which was what originally inspired the introduction of
$inferior_spawn_id.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
Don Breazeal <donb@codesourcery.com>
* gdb.base/multi-forks.exp (continue_to_exit_bp_loc): Expect
output from both inferior_spawn_id and gdb_spawn_id.
When exiting GDB -- whether it's via the "quit" command, via a SIGTERM,
or otherwise -- we should leave the terminal in the state we acquired
it. To that end, we have to undo any modifications that may have been
made by the TUI (ncurses) or by the CLI (readline).
Tested on x86_64 Debian Stretch.
gdb/ChangeLog:
* top.c: Include "tui/tui.h".
(undo_terminal_modifications_before_exit): New static function.
(quit_force): Use it.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp
(test_terminal_settings_preserved_after_cli_exit): New test.
See ChangeLog for details. No functional change intended.
Tested on x86_64 Debian Stretch by verifying that the gdb.log output
remains unchanged for native, gdbserver and extended-gdbserver.
gdb/testsuite/ChangeLog:
* gdb.base/batch-preserve-term-settings.exp: Remove top-level
manipulation of saved_gdbflags.
(test_terminal_settings_preserved): Remove global declaration of
the unused variable pagination_prompt. Remove manipulation of
saved_gdbflags. Use a local variable EXTRA_GDBFLAGS instead of
GDBFLAGS.
The following patch will remove the gdb,noinferiorio setting from the
gdbserver boards, so this bit can be reverted.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/interrupt.exp: Revert back to checking gdb,noinferiorio
at the top.
This forces all tests that rely on stdio to be unbuffered, like
interrupt.exp was adjusted in 6f98576f.
To recap, in some scenarios, GDB or GDBserver can be spawned with
input _not_ connected to a tty, and then tests that rely on stdio fail
with timeouts, because the inferior's stdout and stderr streams end up
fully buffered. Calling gdb_unbuffer_output forces output to be
unbuffered.
See https://sourceware.org/ml/gdb-patches/2015-02/msg00809.html and
https://sourceware.org/ml/gdb-patches/2015-02/msg00819.html.
Tested on x86_64 Fedora 20, native, and against a remote gdbserver
board file that connects to the target with ssh, with and without -t
(create pty).
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-ar-st.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-rt-st.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-strs.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/call-strs.exp: Adjust to step over the
gdb_unbuffer_output call.
* gdb.base/catch-gdb-caused-signals.c: Include
"../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/dprintf.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/ending-run.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/run.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/shlib-call.exp: Adjust to step over the
gdb_unbuffer_output call.
* gdb.base/shmain.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/sizeof.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
* gdb.base/varargs.c: Include "../lib/unbuffer_output.c".
(main): Rename to ...
(test): ... this.
(main): Reimplement.
* gdb.base/varargs.exp: Run to test instead of to main.
* gdb.mi/mi-dprintf.c: Include "../lib/unbuffer_output.c".
(main): Call gdb_unbuffer_output.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-rt-st.exp (print_struct_call): Split "result"
parameter into two new parameters, "inf_result" and "gdb_result".
Expect inferior output and gdb output from $inferior_spawn_id and
$gdb_spawn_id, respectively. Adjust all callers.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-ar-st.exp: Use gdb_test_stdio+multi_line instead
of gdb_test_sequence.
This one is a little more complicated than the other patches in this
series, because of the exit status wrapper handling, requiring a
little state machine.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/a2-run.exp (saw_usage, saw_exit_wrapper)
(saw_spurious_output): Expect inferior output from
$inferior_spawn_id. Use gdb_test_stdio.
This one needed a larger revamp. The issue is that the "info
breakpoints" test at the bottom of the file is broken on targets that
can do both server-side dprintf, and inferior I/O, because then
neither the breakpoint numbers match nor the "already hit N times"
output.
Address that by making the test restart gdb from scratch when
switching between dprintf styles. Test groups are factored into
procedures, and we now use with_test_prefix. While we're changing
test messages, lowercase a few test messages, and then while at it,
modernize a couple things here and there.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/dprintf.exp: Use standard_testfile. Change
prepare_for_testing call.
(srcfile): Don't set.
(restart): New procedure.
(test_dprintf): New procecure, use to continue over dprintfs.
(test_call, test_agent): New procedures, tests moved here.
Restart gdb and recreate dprintfs. Adjust expected output.
There seems to be no point in relying on stdio here. Simply use
gdb_continue_to_end instead.
(not removing the printf calls, as the .c file is half generated.)
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/restore.exp (restore_tests): Use gdb_continue_to_end.
These tests rely on inferior I/O, but that seems pointless and
unrelated here. Simply remove the printf calls, and don't expect
them.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/call-signal-resume.exp: Remove check for
gdb,noinferiorio. Don't expect "no signal". Use gdb_test.
* gdb.base/unwindonsignal.exp: Likewise.
* gdb.base/call-signals.c (gen_signal): Remove printf call.
* gdb.base/unwindonsignal.c (gen_signal): Likewise.
No point in relying on stdio in this test. Simply run to a breakpoint
instead.
gdb/testsuite/ChangeLog:
2015-07-29 Pedro Alves <palves@redhat.com>
* gdb.base/siginfo-addr.c (pass): New function.
(handler): Call it iff si_addr is correct.
* gdb.base/siginfo-addr.exp: Remove gdb_skip_stdio_test check.
Set a breakpoint at "pass" and continue to it.
GDB currently does not promptly quit after receiving a SIGTERM while no
proper target is active. This is because in handle_sigterm we currently
look at target_can_async_p to determine whether to asynchronously quit
GDB using an async signal handler or to asynchronously quit using the
quit flag. However, target_can_async_p is always false under the dummy
target, so under this target we always use the quit flag and not the
async signal handler to signal that GDB should quit. So GDB won't quit
until a code path that checks the quit flag is executed.
To fix this issue, this patch makes the SIGTERM handler no longer
inspect target_can_async_p, and instead makes the handler
unconditionally set the quit flag _and_ mark the corresponding async
signal handler, so that if the target is async (or if it's the dummy
target) then we will likely quit through the async signal handler, and
if it's not async then we will likely quit through the quit flag. This
redundant approach is similar to how we handle SIGINT.
gdb/ChangeLog:
* event-top.c (handle_sigterm): Don't inspect
target_can_async_p. Always set the quit flag and always mark
the async signal handler.
gdb/testsuite/ChangeLog:
* gdb.base/gdb-sigterm-2.exp: New test.
gdb/testsuite/ChangeLog:
* gdb.base/watchpoint.exp (test_complex_watchpoint): Remove
compiler_info references.
* gdb.cp/temargs.exp: Ditto.
* lib/gdb.exp: Unset compiler_info instead of setting to "unknown".
(get_compiler_info): Early exit if already computed. Set compiler_info
to "unknown" if there was a problem.
(test_compiler_info): Add function comment. Call get_compiler_info.
The gdb_skip_xml_test procedure explicitly says that it cannot be
invoked when GDB is running. However, the testcase for "catch
syscall" is wrongly doing that, which is causing a failure on
native-extended-gdbserver tests:
new FAIL: gdb.base/catch-syscall.exp: set tdesc filename /home/gdb-buildbot/fedora-x86-64-3/fedora-x86-64-native-extended-gdbserver-m32/build/gdb/testsuite/outputs/gdb.base/catch-syscall/trivial.xml (got interactive prompt)
This obvious commit fixes this, by calling gdb_exit before gdb_skip_xml_test.
Checked in as obvious.
gdb/testsuite/ChangeLog
2015-07-24 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/catch-syscall.exp: Call gdb_exit before
gdb_skip_xml_test.
New testcase.
gdb/testsuite/ChangeLog
2015-07-15 Aleksandar Ristovski <aristovski@qnx.com
Tests for validate symbol file using build-id.
* gdb.base/solib-mismatch-lib.c: New file.
* gdb.base/solib-mismatch-libmod.c: New file.
* gdb.base/solib-mismatch.c: New file.
* gdb.base/solib-mismatch.exp: New file.
Tracepoints and range stepping are independent features. This patch
skips the gdb.trace/range-stepping.exp test case if the target does not
support range stepping.
gdb/testsuite/ChangeLog:
* gdb.base/range-stepping.exp (gdb_range_stepping_enabled):
Move it to ...
* lib/range-stepping-support.exp (gdb_range_stepping_enabled):
... here.
* gdb.trace/range-stepping.exp: Check that the target supports
range stepping.
This exercises the case of the inferior disappearing while GDB is
debugging it, such as something doing "kill -9 PID" while the program
is stopped under GDB or GDBserver. This triggered a set of internal
errors, fixed by previous patches.
gdb/testsuite/ChangeLog:
2015-07-14 Pedro Alves <palves@redhat.com>
* gdb.base/killed-outside.exp: New file.
* gdb.base/killed-outside.c: New file.
Since the new KFAILs/KPASSs for the infcall tests on x86 and x86_64
targets generated unnecessary noise, this change skips them with
UNSUPPORTED instead.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.exp: On x86 and x86_64 targets, skip the
infcall tests instead of setting up for KFAIL.
Some tests expect the the target is aarch64, but checking target
triplet is not accurate, because target triplet can be aarch64 but
the program is in arm (or aarch32) state.
This patch addes a new proc is_aarch64_target which returns true
if the target is on aarch64 state.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.arch/aarch64-atomic-inst.exp: Check is_aarch64_target
instead of istarget "aarch64*-*-*".
* gdb.arch/aarch64-fp.exp: Likewise.
* gdb.base/float.exp: Likewise.
* gdb.reverse/aarch64.exp: Likewise.
* lib/gdb.exp (is_aarch64_target): New proc.
GDB tests running on arm target should be also run on aarch32
(32-bit mode on aarch64). There should be no difference. It is not
precise to check target triplet to decide which tests should be run,
because if I compiler all the test binary in 32-bit (arm program),
but target triplet is still aarch64, so that these arm specific tests
are skipped.
This patch is to add a new proc is_aarch32_target which return true
if target triplet is arm or the test binary is compiled for arm.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (is_aarch32_target): New proc.
* gdb.arch/arm-bl-branch-dest.exp: Check is_aarch32_target
instead of "istarget "arm*-*-*"".
* gdb.arch/arm-disp-step.exp: Likewise.
* gdb.arch/thumb-bx-pc.exp: Likewise.
* gdb.arch/thumb-prologue.exp: Likewise.
* gdb.arch/thumb-singlestep.exp: Likewise.
* gdb.base/disp-step-syscall.exp: Likewise.
* gdb.base/float.exp: Likewise.
This patch is to enable test_catch_syscall_multi_arch on aarch64.
gdb/testsuite:
2015-07-07 Yao Qi <yao.qi@linaro.org>
* gdb.base/catch-syscall.exp (test_catch_syscall_multi_arch):
Set arch1, arch2, syscall1_name, syscall2_name and syscall_number.
This patch implements the new option "history remove-duplicates", which
controls the removal of duplicate history entries ("off" by default).
The motivation for this option is to be able to reduce the prevalence of
basic commands such as "up" and "down" in the history file. These
common commands crowd out more unique commands in the history file (when
the history file has a fixed size), and they make navigation of the
history file via ^P, ^N and ^R more inconvenient.
The option takes an integer denoting the number of history entries to
look back at for a history entry that is a duplicate of the latest one.
"history remove-duplicates 1" is equivalent to bash's ignoredups option,
and "history remove-duplicates unlimited" is equivalent to bash's
erasedups option.
[ I decided to go with this integer approach instead of a tri-state enum
because it's slightly more flexible and seemingly more intuitive than
leave/erase/ignore. ]
gdb/ChangeLog:
* NEWS: Mention the new option "history remove-duplicates".
* top.c (history_remove_duplicates): New static variable.
(show_history_remove_duplicates): New static function.
(gdb_add_history): Conditionally remove duplicate history
entries.
(init_main): Add "history remove-duplicates" option.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Document the new option
"history remove-duplicates".
gdb/testsuite/ChangeLog:
* gdb.base/history-duplicates.exp: New test.
The implementation is pretty straightforward, with the only caveat being
that the "src", "cmd", "next" and "prev" entries get delibrately added
to the completion list even when the TUI has not yet been initialized
(i.e. has never been enabled during the session), since invoking the
"focus" command with these arguments already works when the TUI has not
yet been initialized.
gdb/ChangeLog:
* tui/tui-win.c (focus_completer): New static function.
(_initialize_tui_win): Set the completion function of the
"focus" command to focus_completer.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Test the completion of the "focus"
command.
Both siginfo-obj.exp and siginfo-thread.exp have the same code
checking the support of geting a type of siginfo for a given arch.
This patch is to move these code into a proc supports_get_siginfo_type.
gdb/testsuite:
2015-06-24 Yao Qi <yao.qi@linaro.org>
* lib/gdb.exp (supports_get_siginfo_type): New proc.
* gdb.base/siginfo-obj.exp: Invoke supports_get_siginfo_type.
* gdb.base/siginfo-thread.exp: Likewise.
The value inside the GDBHISTSIZE environment variable, only if valid,
should override setting the history size through one's .gdbinit file.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Test the interaction between
setting GDBHISTSIZE and setting the history size via .gdbinit.
When GDB reads a nonsensical value for the GDBHISTSIZE environment
variable, i.e. one that is non-numeric or negative, GDB then sets its
history size to 0. This behavior is annoying and also inconsistent
with the behavior of bash.
This patch makes the behavior of invalid GDBHISTSIZE consistent with how
bash handles HISTSIZE. When we encounter a null or out-of-range
GDBHISTSIZE (outside of [0, INT_MAX]) we now set the history size to
unlimited instead of 0. When we encounter a non-numeric GDBHISTSIZE we
do nothing.
gdb/ChangeLog:
PR gdb/16999
* NEWS: Mention new GDBHISTSIZE behavior.
* top.c (init_history): For null or out-of-range GDBHISTSIZE,
set history size to unlimited. Ignore non-numeric GDBHISTSIZE.
gdb/doc/ChangeLog:
PR gdb/16999
* gdb.texinfo (Command History): Mention new GDBHISTSIZE
behavior.
gdb/testsuite/ChangeLog:
PR gdb/16999
* gdb.base/gdbhistsize-history.exp: New test.
The HISTSIZE environment variable is generally expected to be read by
shells, not by applications. Some distros for example globally export
HISTSIZE in /etc/profile -- with the intention that it only affects
shells -- and by doing so it renders useless GDB's own mechanism for
setting the history size via .gdbinit. Also, annoyances may arise when
HISTSIZE is not interpreted the same way by the shell and by GDB, e.g.
PR gdb/16999. That can always be fixed on a shell-by-shell basis but it
may be impossible to be consistent with the behavior of all shells at
once. Finally it just makes sense to not confound shell environment
variables with application environment variables.
gdb/ChangeLog:
* NEWS: Mention that GDBHISTSIZE is read instead of HISTSIZE.
* top.c (init_history): Read from GDBHISTSIZE instead of
HISTSIZE.
(init_main): Refer to GDBHISTSIZE instead of HISTSIZE.
gdb/doc/ChangeLog:
* gdb.texinfo (Command History): Replace occurrences of HISTSIZE
with GDBHISTSIZE.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Replace occurrences of HISTSIZE
with GDBHISTSIZE.
* gdb.base/readline.exp: Likewise.
We still do not handle "set history size unlimited" correctly. In
particular, after writing to the history file, we truncate the history
even if it is unlimited.
This patch makes sure that we do not call history_truncate_file() if the
history is not stifled (i.e. if it's unlimited). This bug causes the
history file to be truncated to zero on exit when one has "set history
size unlimited" in their gdbinit file. Although this code exists in GDB
7.8, the bug is masked by a pre-existing bug that's been only fixed in
GDB 7.9 (PR gdb/17820).
gdb/ChangeLog:
* top.c (gdb_safe_append_history): Do not call
history_truncate_file if the history is not stifled.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp: Add test case to check that
an unlimited history file does not get truncated on exit.
So far the gnu_vector test was limited to "static" aspects of GDB's
vector support, like evaluating vector-valued expressions. This patch
enriches the test and adds checks for GDB's vector ABI support as well.
The new checks particularly verify inferior function calls with vector
arguments and GDB's handling of vector return values.
The test now attempts to compile for the target's "native" architecture,
such that a hardware vector ABI is used if available.
Since GDB has no vector ABI support for x86 and x86_64 targets, most of
the new checks are KFAILed there.
gdb/testsuite/ChangeLog:
* gdb.base/gnu_vector.c: Include stdarg.h and stdio.h.
(VECTOR): New macro. Use it...
(int4, uint4, char4, float4, int2, longlong2, float2, double2):
...for these typedefs.
(int8, char1, int1, double1): New typedefs.
(struct just_int2, struct two_int2): New structures.
(add_some_intvecs, add_many_charvecs, add_various_floatvecs)
(add_structvecs, add_singlevecs): New functions.
(main): Call add_some_intvecs twice.
* gdb.base/gnu_vector.exp: Drop GCC version check; just attempt
the compile and exit upon failure. Try compiling for the "native"
architecture. Test inferior function calls with vector arguments
and vector return value handling with "finish" and "return".
This promotes BFD's struct elf_build_id to the generic struct bfd_build_id,
populated when an ELF or PE BFD is read.
gdb is updated to use that, and to use the build-id to find symbols for PE files
also.
There is currently no generic way to extract the build-id from an object file,
perhaps an option to objdump to do this might make sense?
On x86_64-pc-cygwin, gdb's sepdebug.exp changes:
-# of unsupported tests 1
+# of expected passes 90
I don't seem to get consistent testsuite runs on i686-linux-gnu, but there
don't appear to be any regressions.
bfd/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* elf-bfd.h : Remove struct elf_build_id.
* bfd.c : Add struct bfd_build_id.
* bfd-in2.h: Regenerate.
* elf.c (elfobj_grok_gnu_build_id): Update to use bfd_build_id.
* libpei.h: Add protoype and macros for
bfd_XXi_slurp_codeview_record.
* peXXigen.c (_bfd_XXi_slurp_codeview_record): Make public
* peicode.h (pe_bfd_read_buildid): Add.
(pe_bfd_object_p): Use pe_bfd_read_buildid().
gdb/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* build-id.c: Don't include elf-bfd.h.
(build_id_bfd_get): Use bfd_build_id.
(build_id_verify): Ditto.
* build-id.h: Ditto.
(find_separate_debug_file_by_buildid): Ditto.
* python/py-objfile.c: Don't include elf-bfd.h.
(objfpy_get_build_id) Use bfd_build_id.
(objfpy_build_id_matches, objfpy_lookup_objfile_by_build_id): Ditto.
* coffread.c: Include build-id.h.
(coff_symfile_read): Try find_separate_debug_file_by_buildid.
gdb/doc/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.texinfo (Separate Debug Files): Document that PE is also
supported.
gdb/testsuite/ChangeLog:
2015-06-10 Jon Turney <jon.turney@dronecode.org.uk>
* gdb.base/sepdebug.exp: Add EXEEXT where needed.
* lib/gdb.exp (get_build_id): Teach how to extract build-id from a
PE file.
* lib/future.exp (gdb_find_objdump): Add gdb_find_objdump.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
Use with_test_prefix to avoid duplicating test names when calling
the procedure test_gdbinit_history_setting multiple times.
gdb/testsuite/ChangeLog:
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Use with_test_prefix.
Add layout name completion for the layout command.
gdb/ChangeLog:
* tui/tui-layout.c (layout_completer): New function.
(_initialize_tui_layout): Set completer on layout command.
gdb/testsuite/ChangeLog:
* gdb.base/completion.exp: Add test for completion of layout
names.
Add a new predicate procedure to the gdb.exp library 'skip_tui_tests',
which returns true if the tui is not compiled into gdb.
Make use of this predicate in the gdb.base/tui-layout.exp test as an
example.
gdb/testsuite/ChangeLog:
* lib/gdb.exp (skip_tui_tests): New proc.
* gdb.base/tui-layout.exp: Check skip_tui_tests.
Some buildslaves are showing that this test is failing. E.g.,:
https://sourceware.org/ml/gdb-testers/2015-q2/msg04164.html
The issue is that HISTSIZE is set to 1000 in the environment that runs
the tests (that's the default in Fedora, set in /etc/profile).
We can trivially reproduce it with:
$ HISTSIZE=1000 make check RUNTESTFLAGS="gdbinit-history.exp"
(...)
Running /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.base/gdbinit-history.exp ...
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show history size
FAIL: gdb.base/gdbinit-history.exp: show commands
gdb.log shows:
...
(gdb) set height 0
(gdb) set width 0
(gdb) show history size
The size of the command history is 1000.
(gdb) FAIL: gdb.base/gdbinit-history.exp: show history size
gdb/testsuite/ChangeLog:
2015-05-19 Pedro Alves <palves@redhat.com>
* gdb.base/gdbinit-history.exp (test_gdbinit_history_setting):
Save the whole env array instead of just HOME. Unset HISTSIZE in
the environment while testing. Restore whole environment
afterwards.
This patch is a comprehensive fix for PR 17820 which reports that
using "set history size unlimited" inside one's gdbinit file doesn't
really work.
There are three small changes in this patch. The most important change
this patch makes is to decode the argument of the "size" subcommand
using add_setshow_zuinteger_unlimited_cmd() instead of using
add_setshow_uinteger_cmd(). The new decoder takes an int * and maps
unlimited to -1 whereas the old decoder takes an unsigned int * and maps
unlimited to UINT_MAX. Using the new decoder simplifies our handling of
unlimited and makes it easier to interface with readline which itself
expects a signed-int history size.
The second change is the factoring of the [stifle|unstifle]_history logic
into a common function which is now used by both init_history() and
set_history_size_command(). This is technically the change that fixes
the PR itself.
Thirdly, this patch initializes history_size_setshow_var to -2 to mean
that the variable has not been set yet. Now init_history() tests for -2
instead of 0 to determine whether to give the variable a default value.
This means that having "set history size 0" in one's gdbinit file will
actually keep the history size at 0 and not reset it to 256.
gdb/ChangeLog:
PR gdb/17820
* top.c (history_size_setshow_var): Change type to signed.
Initialize to -2. Update documentation.
(set_readline_history_size): Define.
(set_history_size_command): Use it. Remove logic for handling
out-of-range sizes.
(init_history): Use set_readline_history_size(). Test for a
value of -2 instead of 0 when determining whether to set a
default history size.
(init_main): Decode the argument of the "size" command as a
zuinteger_unlimited.
gdb/testsuite/ChangeLog:
PR gdb/17820
* gdb.base/gdbinit-history.exp: New test.
* gdb.base/gdbinit-history/unlimited/.gdbinit: New file.
* gdb.base/gdbinit-history/zero/.gdbinit: New file.
In my last commit to make gdb.base/coredump-filter.exp be more robust
regarding using arrays in the global namespace, I cleared the
"coredump_var_addr" array like this:
set coredump_var_addr ""
# use coredump_var_addr as an array...
This causes DejaGNU to complain because the variable is first set as
non-array, and the used as an array. The correct way to do this is to
unset the variable using:
unset -nocomplain coredump_var_addr
# use coredump_var_addr as an array...
The "-nocomplain" part is necessary because if the variable doesn't
exist "unset" will not error.
Tested on Fedora 20 x86_64.
gdb/testsuite/ChangeLog:
2015-05-08 Sergio Durigan Junior <sergiodj@redhat.com>
* gdb.base/coredump-filter.exp: Correctly unset
"coredump_var_addr" array.
Hi,
We see some fails in gdb.base/coredump-filter.exp when we do remote
gdbserver testing, like what I did for arm/aarch64 linux testing or
run it with board file remote-gdbserver-on-localhost
$ make check RUNTESTFLAGS='--target_board=remote-gdbserver-on-localhost coredump-filter.exp'
we find that this line in the test doesn't work as expected,
remote_exec target "sh -c \"echo $filter_flag > /proc/$ipid/coredump_filter\""
although such pattern has been used in gdb testsuite somewhere else,
but the special thing here is that we redirect the output to
/proc/$ipid/coredump_filter on the remote target. DejaGNU will
redirect the output from the remote target to local, and looks tcl
gets confused by these two redirection.
After trying pass different parameters to remote_exec and hacking
remote_exec/rsh_exec/local_exec, I got no success, I decide
to give up, and try to update /proc/$ipid/coredump_filter by the c
code directly.
This patch adds a c function set_coredump_filter to update
coredump_filter, and GDB calls it.
gdb/testsuite:
2015-05-08 Yao Qi <yao.qi@linaro.org>
PR gdb/18208
* gdb.base/coredump-filter.c (set_coredump_filter): New function.
* gdb.base/coredump-filter.exp (do_save_core): Call inferior
function set_coredump_filter, and remove remote_exec call.
Remove argument ipid. Callers update.
(top level): Don't get inferior's PID.
Since watch_thread_num.exp was changed to use access watchpoints, the
test case fails on s390 and s390x, since those targets do not support
access watchpoints. This patch skips the test case on such targets.
gdb/testsuite/ChangeLog:
* gdb.base/watch_thread_num.exp: Skip test on targets without
access watchpoints.
Pedro Alves
Ulrich Weigand
Yao Qi
Jan Kratochvil
Simon Marchi
Gabriel Krisman Bertazi
Don Breazeal
Tom Tromey
David Taylor
Sanjoy Das
Yan-Ting Lin
Andrew Burgess
Toshihito Kikuchi
Francis Ricci
Doug Evans
Artemiy Volkov
Doug Evans
Gary Benson
Keith Seitz
Joel Brobecker
Andreas Arnez
Josh Stone
Simon Marchi
Sandra Loosemore
Kevin Buettner
Jose E. Marchesi
Pierre-Marie de Rodat
Patrick Palka
Sergio Durigan Junior
Pierre Langlois
Jon Turney