* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
@ 2015-03-03 14:39 Mark Kettenis
2015-03-03 15:12 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Mark Kettenis @ 2015-03-03 14:39 UTC (permalink / raw)
To: palves; +Cc: gdb-patches
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 3 Mar 2015 13:33:44 +0000
>
> Tested on x86-64 Fedora 20, -m32.
>
> gdb/ChangeLog:
> 2015-03-03 Pedro Alves <palves@redhat.com>
>
> * i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
> the lwp field of ptid. Pass the full ptid to get_thread_regcache.
> * inf-ptrace.c (get_ptrace_pid): New function.
> (inf_ptrace_resume): Use it.
> * linux-nat.c (linux_resume_one_lwp): Pass the LWP's ptid ummodified
> to the lower layer.
> ---
> gdb/ChangeLog | 9 +++++++++
> gdb/i386-linux-nat.c | 5 ++---
> gdb/inf-ptrace.c | 25 ++++++++++++++++++++++---
> gdb/linux-nat.c | 6 +-----
> 4 files changed, 34 insertions(+), 11 deletions(-)
I have some fear this is going to break non-Linux targets.
> --- a/gdb/inf-ptrace.c
> +++ b/gdb/inf-ptrace.c
> @@ -289,6 +289,22 @@ inf_ptrace_stop (struct target_ops *self, ptid_t ptid)
> kill (-inferior_process_group (), SIGINT);
> }
>
> +/* Return which PID to pass to ptrace in order to observe/control the
> + tracee identified by PTID. */
> +
> +static pid_t
> +get_ptrace_pid (ptid_t ptid)
> +{
> + pid_t pid;
> +
> + /* If we have an LWPID to work with, use it. Otherwise, we're
> + dealing with a non-threaded program/target. */
> + pid = ptid_get_lwp (ptid);
> + if (pid == 0)
> + pid = ptid_get_pid (ptid);
> + return pid;
> +}
> +
> /* Resume execution of thread PTID, or all threads if PTID is -1. If
> STEP is nonzero, single-step it. If SIGNAL is nonzero, give it
> that signal. */
> @@ -297,13 +313,16 @@ static void
> inf_ptrace_resume (struct target_ops *ops,
> ptid_t ptid, int step, enum gdb_signal signal)
> {
> - pid_t pid = ptid_get_pid (ptid);
> + pid_t pid;
> +
> int request;
Please don't introduce a blank line here.
> - if (pid == -1)
> + if (ptid_equal (minus_one_ptid, ptid))
> /* Resume all threads. Traditionally ptrace() only supports
> single-threaded processes, so simply resume the inferior. */
> - pid = ptid_get_pid (inferior_ptid);
> + pid = get_ptrace_pid (inferior_ptid);
This defenitely should remain ptid_get_pid(); you want to resume the
entire process and not an individual thread.
> + else
> + pid = get_ptrace_pid (ptid);
This should work for OpenBSD, and probably works for FreeBSD. It
won't work for NetBSD, but they will probably need their own
implementation of this function, so it's probably fine.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 14:39 [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP Mark Kettenis
@ 2015-03-03 15:12 ` Pedro Alves
2015-03-03 15:34 ` Pedro Alves
2015-03-03 16:04 ` Mark Kettenis
0 siblings, 2 replies; 7+ messages in thread
From: Pedro Alves @ 2015-03-03 15:12 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On 03/03/2015 02:39 PM, Mark Kettenis wrote:
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 3 Mar 2015 13:33:44 +0000
>>
>> Tested on x86-64 Fedora 20, -m32.
>>
>> gdb/ChangeLog:
>> 2015-03-03 Pedro Alves <palves@redhat.com>
>>
>> * i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
>> the lwp field of ptid. Pass the full ptid to get_thread_regcache.
>> * inf-ptrace.c (get_ptrace_pid): New function.
>> (inf_ptrace_resume): Use it.
>> * linux-nat.c (linux_resume_one_lwp): Pass the LWP's ptid ummodified
>> to the lower layer.
>> ---
>> gdb/ChangeLog | 9 +++++++++
>> gdb/i386-linux-nat.c | 5 ++---
>> gdb/inf-ptrace.c | 25 ++++++++++++++++++++++---
>> gdb/linux-nat.c | 6 +-----
>> 4 files changed, 34 insertions(+), 11 deletions(-)
>
> I have some fear this is going to break non-Linux targets.
>
>> --- a/gdb/inf-ptrace.c
>> +++ b/gdb/inf-ptrace.c
>> @@ -289,6 +289,22 @@ inf_ptrace_stop (struct target_ops *self, ptid_t ptid)
>> kill (-inferior_process_group (), SIGINT);
>> }
>>
>> +/* Return which PID to pass to ptrace in order to observe/control the
>> + tracee identified by PTID. */
>> +
>> +static pid_t
>> +get_ptrace_pid (ptid_t ptid)
>> +{
>> + pid_t pid;
>> +
>> + /* If we have an LWPID to work with, use it. Otherwise, we're
>> + dealing with a non-threaded program/target. */
>> + pid = ptid_get_lwp (ptid);
>> + if (pid == 0)
>> + pid = ptid_get_pid (ptid);
>> + return pid;
>> +}
>> +
>> /* Resume execution of thread PTID, or all threads if PTID is -1. If
>> STEP is nonzero, single-step it. If SIGNAL is nonzero, give it
>> that signal. */
>> @@ -297,13 +313,16 @@ static void
>> inf_ptrace_resume (struct target_ops *ops,
>> ptid_t ptid, int step, enum gdb_signal signal)
>> {
>> - pid_t pid = ptid_get_pid (ptid);
>> + pid_t pid;
>> +
>> int request;
>
> Please don't introduce a blank line here.
Darn, LOL, I removed one, added another...:
i386_linux_resume (struct target_ops *ops,
ptid_t ptid, int step, enum gdb_signal signal)
{
- int pid = ptid_get_pid (ptid);
-
+ int pid = ptid_get_lwp (ptid);
int request;
I'll remove the one I added...
>
>> - if (pid == -1)
>> + if (ptid_equal (minus_one_ptid, ptid))
>> /* Resume all threads. Traditionally ptrace() only supports
>> single-threaded processes, so simply resume the inferior. */
>> - pid = ptid_get_pid (inferior_ptid);
>> + pid = get_ptrace_pid (inferior_ptid);
>
> This defenitely should remain ptid_get_pid(); you want to resume the
> entire process and not an individual thread.
My thinking is that it doesn't matter in practice.
Or is it that if there are multiple kernel threads in the
process, ptrace(PTRACE_CONT, PID) on bsd actually resumes
them all? Then other things must be broken anyway.
I was assuming that on BSD targets that use this method,
there would only be one thread in the core thread list, and
it would either have LWPID==0, or have PID==LWPID, thus it didn't
matter if get_ptrace_pid returned the PID or the LWPID.
If there anything that actually creates other threads with
a different LWPID on these targets?
>
>> + else
>> + pid = get_ptrace_pid (ptid);
>
> This should work for OpenBSD, and probably works for FreeBSD. It
> won't work for NetBSD, but they will probably need their own
> implementation of this function, so it's probably fine.
>
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 15:12 ` Pedro Alves
@ 2015-03-03 15:34 ` Pedro Alves
2015-03-03 16:34 ` Pedro Alves
2015-03-03 16:04 ` Mark Kettenis
1 sibling, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2015-03-03 15:34 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On 03/03/2015 03:12 PM, Pedro Alves wrote:
> On 03/03/2015 02:39 PM, Mark Kettenis wrote:
>>> - if (pid == -1)
>>> + if (ptid_equal (minus_one_ptid, ptid))
>>> /* Resume all threads. Traditionally ptrace() only supports
>>> single-threaded processes, so simply resume the inferior. */
>>> - pid = ptid_get_pid (inferior_ptid);
>>> + pid = get_ptrace_pid (inferior_ptid);
>>
>> This defenitely should remain ptid_get_pid(); you want to resume the
>> entire process and not an individual thread.
>
> My thinking is that it doesn't matter in practice.
>
> Or is it that if there are multiple kernel threads in the
> process, ptrace(PTRACE_CONT, PID) on bsd actually resumes
> them all? Then other things must be broken anyway.
>
> I was assuming that on BSD targets that use this method,
> there would only be one thread in the core thread list, and
> it would either have LWPID==0, or have PID==LWPID, thus it didn't
> matter if get_ptrace_pid returned the PID or the LWPID.
>
> If there anything that actually creates other threads with
> a different LWPID on these targets?
>
>>
>>> + else
>>> + pid = get_ptrace_pid (ptid);
>>
>> This should work for OpenBSD, and probably works for FreeBSD. It
>> won't work for NetBSD, but they will probably need their own
>> implementation of this function, so it's probably fine.
>>
>
In any case, I agree it's at least clearer. I'm testing this.
Thanks.
From b8480e9cfcc2107b81751084c01a262eb1d52c74 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 3 Mar 2015 15:27:54 +0000
Subject: [PATCH] inf-ptrace.c: use ptid_get_pid when resuming all threads
In this case, we want to resume the entire process and not an
individual thread. Using the overall process id is clearer and more
correct.
gdb/
2015-03-03 Pedro Alves <palves@redhat.com>
* inf-ptrace.c (inf_ptrace_resume): Remove spurious whitespace.
Use ptid_get_pid to get the overall process id when resuming all
threads.
---
gdb/ChangeLog | 6 ++++++
gdb/inf-ptrace.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 31a672e..20250e4 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,11 @@
2015-03-03 Pedro Alves <palves@redhat.com>
+ * inf-ptrace.c (inf_ptrace_resume): Remove spurious whitespace.
+ Use ptid_get_pid to get the overall process id when resuming all
+ threads.
+
+2015-03-03 Pedro Alves <palves@redhat.com>
+
* i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
the lwp field of ptid. Pass the full ptid to get_thread_regcache.
* inf-ptrace.c (get_ptrace_pid): New function.
diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
index 606bdb4..3502a12 100644
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -314,13 +314,12 @@ inf_ptrace_resume (struct target_ops *ops,
ptid_t ptid, int step, enum gdb_signal signal)
{
pid_t pid;
-
int request;
if (ptid_equal (minus_one_ptid, ptid))
/* Resume all threads. Traditionally ptrace() only supports
single-threaded processes, so simply resume the inferior. */
- pid = get_ptrace_pid (inferior_ptid);
+ pid = ptid_get_pid (inferior_ptid);
else
pid = get_ptrace_pid (ptid);
--
1.9.3
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 15:12 ` Pedro Alves
2015-03-03 15:34 ` Pedro Alves
@ 2015-03-03 16:04 ` Mark Kettenis
2015-03-03 16:25 ` Pedro Alves
1 sibling, 1 reply; 7+ messages in thread
From: Mark Kettenis @ 2015-03-03 16:04 UTC (permalink / raw)
To: palves; +Cc: gdb-patches
> Date: Tue, 03 Mar 2015 15:12:48 +0000
> From: Pedro Alves <palves@redhat.com>
>
> On 03/03/2015 02:39 PM, Mark Kettenis wrote:
> >> From: Pedro Alves <palves@redhat.com>
> >> Date: Tue, 3 Mar 2015 13:33:44 +0000
> >>
> >> Tested on x86-64 Fedora 20, -m32.
> >>
> >> gdb/ChangeLog:
> >> 2015-03-03 Pedro Alves <palves@redhat.com>
> >>
> >> * i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
> >> the lwp field of ptid. Pass the full ptid to get_thread_regcache.
> >> * inf-ptrace.c (get_ptrace_pid): New function.
> >> (inf_ptrace_resume): Use it.
> >> * linux-nat.c (linux_resume_one_lwp): Pass the LWP's ptid ummodified
> >> to the lower layer.
> >> ---
> >> gdb/ChangeLog | 9 +++++++++
> >> gdb/i386-linux-nat.c | 5 ++---
> >> gdb/inf-ptrace.c | 25 ++++++++++++++++++++++---
> >> gdb/linux-nat.c | 6 +-----
> >> 4 files changed, 34 insertions(+), 11 deletions(-)
> >
> > I have some fear this is going to break non-Linux targets.
> >
> >> --- a/gdb/inf-ptrace.c
> >> +++ b/gdb/inf-ptrace.c
> >> - if (pid == -1)
> >> + if (ptid_equal (minus_one_ptid, ptid))
> >> /* Resume all threads. Traditionally ptrace() only supports
> >> single-threaded processes, so simply resume the inferior. */
> >> - pid = ptid_get_pid (inferior_ptid);
> >> + pid = get_ptrace_pid (inferior_ptid);
> >
> > This defenitely should remain ptid_get_pid(); you want to resume the
> > entire process and not an individual thread.
>
> My thinking is that it doesn't matter in practice.
>
> Or is it that if there are multiple kernel threads in the
> process, ptrace(PTRACE_CONT, PID) on bsd actually resumes
> them all? Then other things must be broken anyway.
I can only speak for OpenBSD here, but yes, on OpenBSD, if you pass
"PID" here, all threads within a process are resumed. If you want to
resume an individual thread, you need to pass its thread ID. Thread
IDs are also integers, but start at THREAD_PID_OFFSET, which is
currently defined as 1000000.
Are things broken? Perhaps. GDB used to properly support an
all-stop/all-go model, and things still seem to work mostly ok.
Perhaps this diff will actually make things better if there are places
where GDB wants to resume or step a single thread that isn't the
thread that stopped the process in the first place.
I've always considered it a serious flaw that Linux doesn't have a way
to resume the entire process and that we need almost 5000 lines of
code to deal with the consequences.
> I was assuming that on BSD targets that use this method,
> there would only be one thread in the core thread list, and
> it would either have LWPID==0, or have PID==LWPID, thus it didn't
> matter if get_ptrace_pid returned the PID or the LWPID.
That assumption is incorrect. I see that this assumption has made its
way into infrun.c:
inferior_ptid = ptid_build (child_pid, child_pid, 0);
That's wrong. The OS-specific code should fill in the LWPID part with
the appropriate value by using thread_change_ptid(). AFAICT, the
linux-nat.c code does that properly.
> If there anything that actually creates other threads with
> a different LWPID on these targets?
The initial thread ID of an OpenBSD process will be PID + THREAD_PID_OFFSET.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 16:04 ` Mark Kettenis
@ 2015-03-03 16:25 ` Pedro Alves
2015-03-03 17:06 ` Pedro Alves
0 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2015-03-03 16:25 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On 03/03/2015 04:04 PM, Mark Kettenis wrote:
>> > Date: Tue, 03 Mar 2015 15:12:48 +0000
>> > From: Pedro Alves <palves@redhat.com>
>> >
>> > Or is it that if there are multiple kernel threads in the
>> > process, ptrace(PTRACE_CONT, PID) on bsd actually resumes
>> > them all? Then other things must be broken anyway.
> I can only speak for OpenBSD here, but yes, on OpenBSD, if you pass
> "PID" here, all threads within a process are resumed. If you want to
> resume an individual thread, you need to pass its thread ID. Thread
> IDs are also integers, but start at THREAD_PID_OFFSET, which is
> currently defined as 1000000.
>
> Are things broken? Perhaps. GDB used to properly support an
> all-stop/all-go model, and things still seem to work mostly ok.
> Perhaps this diff will actually make things better if there are places
> where GDB wants to resume or step a single thread that isn't the
> thread that stopped the process in the first place.
Yes, I assume so. Things like schedlock and stepping over a
breakpoint must have been subtly broken thus far, if they have
been letting all threads run while core gdb wants only one
thread to run.
>
> I've always considered it a serious flaw that Linux doesn't have a way
> to resume the entire process and that we need almost 5000 lines of
> code to deal with the consequences.
:-)
>
>> > I was assuming that on BSD targets that use this method,
>> > there would only be one thread in the core thread list, and
>> > it would either have LWPID==0, or have PID==LWPID, thus it didn't
>> > matter if get_ptrace_pid returned the PID or the LWPID.
> That assumption is incorrect.
OK.
> I see that this assumption has made its way into infrun.c:
>
> inferior_ptid = ptid_build (child_pid, child_pid, 0);
>
> That's wrong. The OS-specific code should fill in the LWPID part with
> the appropriate value by using thread_change_ptid(). AFAICT, the
> linux-nat.c code does that properly.
I think you're pointing at the follow fork code. That was born out
of a generalization of code that used to live in linux-nat.c, inf-ptrace.c,
etc. (d83ad864). The old inf-ptrace.c code used to do:
/* Switch inferior_ptid out of the parent's way. */
inferior_ptid = pid_to_ptid (fpid);
/* Delete the parent. */
detach_inferior (pid);
add_thread_silent (inferior_ptid);
'child_pid' is set at the top of follow_fork_inferior, like:
child_pid
= ptid_get_pid (inferior_thread ()->pending_follow.value.related_pid);
I think I even remember that long ago "related_pid" used to be
a single int, not a ptid.
This is again another case of losing information. I think we could
easily make that:
child_pid = inferior_thread ()->pending_follow.value.related_pid;
and drop that ptid_build, and things should work everywhere.
I have no idea if "follow fork" actually works on BSD targets correctly.
A buildbot slave would catch breakages like these. ( hint :-) )
>
>> > If there anything that actually creates other threads with
>> > a different LWPID on these targets?
> The initial thread ID of an OpenBSD process will be PID + THREAD_PID_OFFSET.
>
Thanks, didn't know that.
Pedro Alves
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 15:34 ` Pedro Alves
@ 2015-03-03 16:34 ` Pedro Alves
0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2015-03-03 16:34 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On 03/03/2015 03:34 PM, Pedro Alves wrote:
> On 03/03/2015 03:12 PM, Pedro Alves wrote:
>> On 03/03/2015 02:39 PM, Mark Kettenis wrote:
>
>>>> - if (pid == -1)
>>>> + if (ptid_equal (minus_one_ptid, ptid))
>>>> /* Resume all threads. Traditionally ptrace() only supports
>>>> single-threaded processes, so simply resume the inferior. */
>>>> - pid = ptid_get_pid (inferior_ptid);
>>>> + pid = get_ptrace_pid (inferior_ptid);
>>>
>>> This defenitely should remain ptid_get_pid(); you want to resume the
>>> entire process and not an individual thread.
> In any case, I agree it's at least clearer. I'm testing this.
Alright, pushed as below. I dropped the "clearer" comment, as as
discussed, it's a correctness issue.
Thanks!
---
From c1593e4fa9901c65a32e85c3c5d3ec41598be887 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 3 Mar 2015 16:28:15 +0000
Subject: [PATCH] inf-ptrace.c: use ptid_get_pid when resuming all threads
In this case, we want to resume the entire process and not an
individual thread.
gdb/
2015-03-03 Pedro Alves <palves@redhat.com>
* inf-ptrace.c (inf_ptrace_resume): Remove spurious whitespace.
Use ptid_get_pid to get the overall process id when resuming all
threads.
---
gdb/ChangeLog | 6 ++++++
gdb/inf-ptrace.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 31a672e..20250e4 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,5 +1,11 @@
2015-03-03 Pedro Alves <palves@redhat.com>
+ * inf-ptrace.c (inf_ptrace_resume): Remove spurious whitespace.
+ Use ptid_get_pid to get the overall process id when resuming all
+ threads.
+
+2015-03-03 Pedro Alves <palves@redhat.com>
+
* i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
the lwp field of ptid. Pass the full ptid to get_thread_regcache.
* inf-ptrace.c (get_ptrace_pid): New function.
diff --git a/gdb/inf-ptrace.c b/gdb/inf-ptrace.c
index 606bdb4..3502a12 100644
--- a/gdb/inf-ptrace.c
+++ b/gdb/inf-ptrace.c
@@ -314,13 +314,12 @@ inf_ptrace_resume (struct target_ops *ops,
ptid_t ptid, int step, enum gdb_signal signal)
{
pid_t pid;
-
int request;
if (ptid_equal (minus_one_ptid, ptid))
/* Resume all threads. Traditionally ptrace() only supports
single-threaded processes, so simply resume the inferior. */
- pid = get_ptrace_pid (inferior_ptid);
+ pid = ptid_get_pid (inferior_ptid);
else
pid = get_ptrace_pid (ptid);
--
1.9.3
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
2015-03-03 16:25 ` Pedro Alves
@ 2015-03-03 17:06 ` Pedro Alves
0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2015-03-03 17:06 UTC (permalink / raw)
To: Mark Kettenis; +Cc: gdb-patches
On 03/03/2015 04:25 PM, Pedro Alves wrote:
> On 03/03/2015 04:04 PM, Mark Kettenis wrote:
>> I see that this assumption has made its way into infrun.c:
>>
>> inferior_ptid = ptid_build (child_pid, child_pid, 0);
>>
>> That's wrong. The OS-specific code should fill in the LWPID part with
>> the appropriate value by using thread_change_ptid(). AFAICT, the
>> linux-nat.c code does that properly.
>
> I think you're pointing at the follow fork code. That was born out
> of a generalization of code that used to live in linux-nat.c, inf-ptrace.c,
> etc. (d83ad864). The old inf-ptrace.c code used to do:
>
> /* Switch inferior_ptid out of the parent's way. */
> inferior_ptid = pid_to_ptid (fpid);
>
> /* Delete the parent. */
> detach_inferior (pid);
>
> add_thread_silent (inferior_ptid);
>
>
> 'child_pid' is set at the top of follow_fork_inferior, like:
>
> child_pid
> = ptid_get_pid (inferior_thread ()->pending_follow.value.related_pid);
>
> I think I even remember that long ago "related_pid" used to be
> a single int, not a ptid.
>
> This is again another case of losing information. I think we could
> easily make that:
>
> child_pid = inferior_thread ()->pending_follow.value.related_pid;
>
> and drop that ptid_build, and things should work everywhere.
>
> I have no idea if "follow fork" actually works on BSD targets correctly.
> A buildbot slave would catch breakages like these. ( hint :-) )
Like this. Let me know what you think.
----
From c557c13f6bfe0126dd9ab74576951b127fd39531 Mon Sep 17 00:00:00 2001
From: Pedro Alves <palves@redhat.com>
Date: Tue, 3 Mar 2015 16:36:28 +0000
Subject: [PATCH] follow-fork: don't lose the ptids as set by the target
This Linuxism has made its way into infrun.c, in the follow-fork code:
inferior_ptid = ptid_build (child_pid, child_pid, 0);
The OS-specific code should fill in the LWPID, TID parts with the
appropriate values, if any, and the core code should not be peeking at
the components of the ptids.
gdb/
2015-03-03 Pedro Alves <palves@redhat.com>
* infrun.c (follow_fork_inferior): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components. Adjust verbose output
to use target_pid_to_str.
* linux-nat.c (linux_child_follow_fork): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components.
---
gdb/infrun.c | 33 ++++++++++++++-------------------
gdb/linux-nat.c | 15 +++++++--------
2 files changed, 21 insertions(+), 27 deletions(-)
diff --git a/gdb/infrun.c b/gdb/infrun.c
index f87ed4c..abfeeee 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -408,15 +408,12 @@ static int
follow_fork_inferior (int follow_child, int detach_fork)
{
int has_vforked;
- int parent_pid, child_pid;
+ ptid_t parent_ptid, child_ptid;
has_vforked = (inferior_thread ()->pending_follow.kind
== TARGET_WAITKIND_VFORKED);
- parent_pid = ptid_get_lwp (inferior_ptid);
- if (parent_pid == 0)
- parent_pid = ptid_get_pid (inferior_ptid);
- child_pid
- = ptid_get_pid (inferior_thread ()->pending_follow.value.related_pid);
+ parent_ptid = inferior_ptid;
+ child_ptid = inferior_thread ()->pending_follow.value.related_pid;
if (has_vforked
&& !non_stop /* Non-stop always resumes both branches. */
@@ -460,10 +457,9 @@ holding the child stopped. Try \"set detach-on-fork\" or \
{
target_terminal_ours_for_output ();
fprintf_filtered (gdb_stdlog,
- _("Detaching after %s from "
- "child process %d.\n"),
+ _("Detaching after %s from child %s.\n"),
has_vforked ? "vfork" : "fork",
- child_pid);
+ target_pid_to_str (child_ptid));
}
}
else
@@ -472,7 +468,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \
struct cleanup *old_chain;
/* Add process to GDB's tables. */
- child_inf = add_inferior (child_pid);
+ child_inf = add_inferior (ptid_get_pid (child_ptid));
parent_inf = current_inferior ();
child_inf->attach_flag = parent_inf->attach_flag;
@@ -483,7 +479,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \
old_chain = save_inferior_ptid ();
save_current_program_space ();
- inferior_ptid = ptid_build (child_pid, child_pid, 0);
+ inferior_ptid = child_ptid;
add_thread (inferior_ptid);
child_inf->symfile_flags = SYMFILE_NO_READ;
@@ -549,17 +545,16 @@ holding the child stopped. Try \"set detach-on-fork\" or \
{
target_terminal_ours_for_output ();
fprintf_filtered (gdb_stdlog,
- _("Attaching after process %d "
- "%s to child process %d.\n"),
- parent_pid,
+ _("Attaching after %s %s to child %s.\n"),
+ target_pid_to_str (parent_ptid),
has_vforked ? "vfork" : "fork",
- child_pid);
+ target_pid_to_str (child_ptid));
}
/* Add the new inferior first, so that the target_detach below
doesn't unpush the target. */
- child_inf = add_inferior (child_pid);
+ child_inf = add_inferior (ptid_get_pid (child_ptid));
parent_inf = current_inferior ();
child_inf->attach_flag = parent_inf->attach_flag;
@@ -596,8 +591,8 @@ holding the child stopped. Try \"set detach-on-fork\" or \
target_terminal_ours_for_output ();
fprintf_filtered (gdb_stdlog,
_("Detaching after fork from "
- "child process %d.\n"),
- child_pid);
+ "child %s.\n"),
+ target_pid_to_str (child_ptid));
}
target_detach (NULL, 0);
@@ -609,7 +604,7 @@ holding the child stopped. Try \"set detach-on-fork\" or \
this new thread, before cloning the program space, and
informing the solib layer about this new process. */
- inferior_ptid = ptid_build (child_pid, child_pid, 0);
+ inferior_ptid = child_ptid;
add_thread (inferior_ptid);
/* If this is a vfork child, then the address-space is shared
diff --git a/gdb/linux-nat.c b/gdb/linux-nat.c
index cb10e2c..57bd1e7 100644
--- a/gdb/linux-nat.c
+++ b/gdb/linux-nat.c
@@ -387,20 +387,19 @@ linux_child_follow_fork (struct target_ops *ops, int follow_child,
int status = W_STOPCODE (0);
struct cleanup *old_chain;
int has_vforked;
+ ptid_t parent_ptid, child_ptid;
int parent_pid, child_pid;
has_vforked = (inferior_thread ()->pending_follow.kind
== TARGET_WAITKIND_VFORKED);
- parent_pid = ptid_get_lwp (inferior_ptid);
- if (parent_pid == 0)
- parent_pid = ptid_get_pid (inferior_ptid);
- child_pid
- = ptid_get_pid (inferior_thread ()->pending_follow.value.related_pid);
-
+ parent_ptid = inferior_ptid;
+ child_ptid = inferior_thread ()->pending_follow.value.related_pid;
+ parent_pid = ptid_get_lwp (parent_ptid);
+ child_pid = ptid_get_lwp (child_ptid);
/* We're already attached to the parent, by default. */
old_chain = save_inferior_ptid ();
- inferior_ptid = ptid_build (child_pid, child_pid, 0);
+ inferior_ptid = child_ptid;
child_lp = add_lwp (inferior_ptid);
child_lp->stopped = 1;
child_lp->last_resume_kind = resume_stop;
@@ -457,7 +456,7 @@ linux_child_follow_fork (struct target_ops *ops, int follow_child,
{
struct lwp_info *parent_lp;
- parent_lp = find_lwp_pid (pid_to_ptid (parent_pid));
+ parent_lp = find_lwp_pid (parent_ptid);
gdb_assert (linux_supports_tracefork () >= 0);
if (linux_supports_tracevforkdone ())
--
1.9.3
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-03-03 17:06 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-03 14:39 [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP Mark Kettenis
2015-03-03 15:12 ` Pedro Alves
2015-03-03 15:34 ` Pedro Alves
2015-03-03 16:34 ` Pedro Alves
2015-03-03 16:04 ` Mark Kettenis
2015-03-03 16:25 ` Pedro Alves
2015-03-03 17:06 ` Pedro Alves
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox