[ Backport of master commit b73715df01. ]
When debugging any of the testcases added by this commit, which do a
vfork in a thread with "set follow-fork-mode child" + "set
detach-on-fork on", we run into this assertion:
...
src/gdb/nat/x86-linux-dregs.c:146: internal-error: \
void x86_linux_update_debug_registers(lwp_info*): \
Assertion `lwp_is_stopped (lwp)' failed.
...
The assert is caused by the following: the vfork-child exit or exec
event is handled by handle_vfork_child_exec_or_exit, which calls
target_detach to detach from the vfork parent. During target_detach
we call linux_nat_target::detach, which:
However, during the second step we run into this code in
stop_wait_callback:
...
/* If this is a vfork parent, bail out, it is not going to report
any SIGSTOP until the vfork is done with. */
if (inf->vfork_child != NULL)
return 0;
...
and we don't wait for the threads to be stopped, which results in this
assert in x86_linux_update_debug_registers triggering during the third
step:
...
gdb_assert (lwp_is_stopped (lwp));
...
The fix is to reset the vfork parent's vfork_child field before
calling target_detach in handle_vfork_child_exec_or_exit. There's
already similar code for the other paths handled by
handle_vfork_child_exec_or_exit, so this commit refactors the code a
bit so that all paths share the same code.
The new tests cover both a vfork child exiting, and a vfork child
execing, since both cases would trigger the assertion.
The new testcases also exercise following the vfork children with "set
detach-on-fork off", since it doesn't seem to be tested anywhere.
Tested on x86_64-linux, using native and native-gdbserver.
gdb/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* infrun.c (handle_vfork_child_exec_or_exit): Reset vfork parent's
vfork_child field before calling target_detach.
gdb/testsuite/ChangeLog:
2019-04-18 Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR gdb/24454
* gdb.threads/vfork-follow-child-exec.c: New file.
* gdb.threads/vfork-follow-child-exec.exp: New file.
* gdb.threads/vfork-follow-child-exit.c: New file.
* gdb.threads/vfork-follow-child-exit.exp: New file.
[ Backport of commit 766f883622. ]
Calls to error () can cause SIGTTOU to send gdb to the background.
For example, on an Arm build:
(gdb) b main
Breakpoint 1 at 0x10774: file /build/gdb/testsuite/../../../src/binutils-gdb/gdb/testsuite/gdb.base/watchpoint.c, line 174.
(gdb) r
Starting program: /build/gdb/testsuite/outputs/gdb.base/watchpoint/watchpoint
[1]+ Stopped ../gdb ./outputs/gdb.base/watchpoint/watchpoint
localhost$ fg
../gdb ./outputs/gdb.base/watchpoint/watchpoint
Cannot parse expression `.L1199 4@r4'.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
The SIGTTOU is raised whilst inside a syscall during the call to tcdrain.
Fix is to use scoped_ignore_sigttou to ensure SIGTTOU is blocked.
In addition fix include comments - job_control is not included via terminal.h
gdb/ChangeLog:
* event-top.c: Remove include comment.
* inflow.c (class scoped_ignore_sigttou): Move from here...
* inflow.h (class scoped_ignore_sigttou): ...to here.
* ser-unix.c (hardwire_drain_output): Block SIGTTOU during drain.
* top.c: Remove include comment.
[ Backport of master commit ea142fbfc9. ]
When a binary is built using PIE, reloading the file will cause GDB to error
on restart. For example:
gdb ./a.out
(gdb) break main
(gdb) run
(gdb) file ./a.out
(gdb) continue
Will cause GDB to error with:
Continuing.
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x9e0
Command aborted.
This is due to the symbol offsets not being relocated after reloading the file.
Fix is to ensure solib_create_inferior_hook is called, in the same manner as
infrun.c:follow_exec().
Expand the idempotent test to cover PIE scenarios.
gdb/ChangeLog:
* symfile.c (symbol_file_command): Call solib_create_inferior_hook.
gdb/testsuite/ChangeLog:
* gdb.base/break-idempotent.exp: Test both PIE and non PIE.
[ Backport of master commit 968aa7ae38. ]
Recent versions of Ubuntu and Debian default GCC to enable pie.
In dump.exp, pie will causes addresses to be out of range for IHEX.
In break-interp.exp, pie is explicitly set for some tests and assumed
to be disabled for the remainder.
Ensure pie is disabled for these tests when required.
In addition, add a pie option to gdb_compile to match the nopie option
and simplify use.
gdb/testsuite/ChangeLog:
* README: Add pie options.
* gdb.base/break-interp.exp: Ensure pie is disabled.
* gdb.base/dump.exp: Likewise.
* lib/gdb.exp (gdb_compile): Add pie option.
[ Backport of master commit 3d507ff23b. ]
Pedro pointed out an issue in the cp_print_value_fields
patch, aka the fix for PR c++/20020.
This patch addresses the issue. Tested on x86-64 Fedora 29.
gdb/testsuite/ChangeLog
2019-06-27 Tom Tromey <tromey@adacore.com>
* gdb.cp/constexpr-field.exp: Use setup_xfail.
[ Backport of master commit 4330d61dfb. ]
PR c++/20020 concerns a crash in cp_print_value_fields. The immediate
cause is that cp_print_value_fields does not handle the case where
value_static_field fails. This is fixed in this patch by calling
cp_print_static_field from the "try" block.
Digging a bit deeper, the error occurs because GCC does not emit a
DW_AT_const_value for a static constexpr member appearing in a
template class. I've filed a GCC bug for this.
Tested on x86-64 Fedora 29.
gdb/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* cp-valprint.c (cp_print_value_fields): Call
cp_print_static_field inside "try".
gdb/testsuite/ChangeLog
2019-05-29 Tom Tromey <tromey@adacore.com>
PR c++/20020:
* gdb.cp/constexpr-field.exp: New file.
* gdb.cp/constexpr-field.cc: New file.
