From: Pedro Alves <palves@redhat.com>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] Linux/ptrace: don't convert ptids when asking inf-ptrace layer to resume LWP
Date: Tue, 03 Mar 2015 15:12:00 -0000 [thread overview]
Message-ID: <54F5CF70.2090706@redhat.com> (raw)
In-Reply-To: <201503031439.t23EdHZv020814@glazunov.sibelius.xs4all.nl>
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
next prev parent reply other threads:[~2015-03-03 15:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 14:39 Mark Kettenis
2015-03-03 15:12 ` Pedro Alves [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F5CF70.2090706@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox