This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
- From: Pedro Alves <palves at redhat dot com>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 03 Mar 2015 16:25:08 +0000
- Subject: Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
- Authentication-results: sourceware.org; auth=none
- References: <201503031439 dot t23EdHZv020814 at glazunov dot sibelius dot xs4all dot nl> <54F5CF70 dot 2090706 at redhat dot com> <201503031604 dot t23G4JqR008694 at glazunov dot sibelius dot xs4all dot nl>
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