[1/3] Make remote follow fork 'Detaching' message match native
Commit Message
This patch fixes a couple of failures in gdb.base/foll-vfork.exp for
extended-remote targets. The failures were the result of the
verbose/debug "Detaching..." messages in infrun.c:follow_fork_inferior
not matching what was expected in the extended-remote case.
The path modifies the ptids used in the messages to ensure that they
print "process nnn" instead of (possibly) "Thread nnn.nnn". The
ptids for the native case are already in this form, so there the
change has no effect. The ptids in the extended-remote case must be
reported by gdbserver in the (pid,pid,0) form in order to later
identify and remove new fork children that are reported prematurely
by remote_update_thread_list. So here we generate process-style ptids
to get identical messages in both native and extended-remote cases.
OK?
thanks
--Don
gdb/
2015-05-22 Don Breazeal <donb@codesourcery.com>
* infrun.c (follow_fork_inferior): Ensure the use of
process-style ptids (pid,0,0) in verbose/debug "Detaching"
messages.
---
gdb/infrun.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
Comments
On 05/22/2015 07:55 PM, Don Breazeal wrote:
> This patch fixes a couple of failures in gdb.base/foll-vfork.exp for
> extended-remote targets. The failures were the result of the
> verbose/debug "Detaching..." messages in infrun.c:follow_fork_inferior
> not matching what was expected in the extended-remote case.
>
> The path modifies the ptids used in the messages to ensure that they
> print "process nnn" instead of (possibly) "Thread nnn.nnn".
...
> The
> ptids for the native case are already in this form, so there the
> change has no effect.
This isn't true. What happens is that linux_nat_pid_to_str
gives (pid,pid,0) special treatment:
(top-gdb) p ptid
$2 = {pid = 14246, lwp = 14246, tid = 0}
(top-gdb) bt
#0 linux_nat_pid_to_str (ops=0xe357f0, ptid=...) at /home/pedro/gdb/mygit/src/gdb/linux-nat.c:4078
#1 0x0000000000675bb5 in delegate_pid_to_str (self=0xe357f0, arg1=...) at /home/pedro/gdb/mygit/src/gdb/target-delegates.c:1438
#2 0x0000000000682641 in target_pid_to_str (ptid=...) at /home/pedro/gdb/mygit/src/gdb/target.c:2212
#3 0x00000000006245b2 in follow_fork_inferior (follow_child=0, detach_fork=1) at /home/pedro/gdb/mygit/src/gdb/infrun.c:449
#4 0x0000000000624e7e in follow_fork () at /home/pedro/gdb/mygit/src/gdb/infrun.c:722
#5 0x000000000062a531 in handle_inferior_event_1 (ecs=0x7fffffffd180) at /home/pedro/gdb/mygit/src/gdb/infrun.c:4072
> The ptids in the extended-remote case must be
> reported by gdbserver in the (pid,pid,0) form in order to later
> identify and remove new fork children that are reported prematurely
> by remote_update_thread_list.
(so this bit is actually irrelevant)
> So here we generate process-style ptids
> to get identical messages in both native and extended-remote cases.
>
> OK?
Still, detach is a process-wide operation, so this makes
sense anyway.
OK with commit log fixed.
Thanks,
Pedro Alves
@@ -445,11 +445,14 @@ holding the child stopped. Try \"set detach-on-fork\" or \
if (info_verbose || debug_infrun)
{
+ /* Ensure that we have a process ptid. */
+ ptid_t process_ptid = pid_to_ptid (ptid_get_pid (child_ptid));
+
target_terminal_ours_for_output ();
fprintf_filtered (gdb_stdlog,
_("Detaching after %s from child %s.\n"),
has_vforked ? "vfork" : "fork",
- target_pid_to_str (child_ptid));
+ target_pid_to_str (process_ptid));
}
}
else
@@ -578,11 +581,14 @@ holding the child stopped. Try \"set detach-on-fork\" or \
{
if (info_verbose || debug_infrun)
{
+ /* Ensure that we have a process ptid. */
+ ptid_t process_ptid = pid_to_ptid (ptid_get_pid (child_ptid));
+
target_terminal_ours_for_output ();
fprintf_filtered (gdb_stdlog,
_("Detaching after fork from "
"child %s.\n"),
- target_pid_to_str (child_ptid));
+ target_pid_to_str (process_ptid));
}
target_detach (NULL, 0);