Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Simon Marchi <simon.marchi@ericsson.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH] Remove lwp -> pid conversion in linux_nat_xfer_partial
Date: Wed, 22 Mar 2017 01:01:00 -0000	[thread overview]
Message-ID: <cf900897-3e74-aa71-32b8-4f6c96e6a0a6@redhat.com> (raw)
In-Reply-To: <3da10b16ca20d771c39f07a73235c7d3@polymtl.ca>

On 03/22/2017 12:42 AM, Simon Marchi wrote:

>>> There is also linux_proc_xfer_partial and linux_proc_xfer_spu, which
>>> both only use the pid field of inferior_ptid and ignore lwp.  However,
>>> since they use "/proc/<pid>", using the id of any thread in the process
>>> will give the same result (AFAIK).
>>
>> It's generally better to use the lwp id:
>>
>> - some files under /proc/<pid>/ may not work if the <pid> thread is
>>   running, just like ptrace requires a stopped thread.  The current
>>   thread's lwp id is more likely to be in the necessary state (stopped).
>>
>> - if the leader exits, and goes zombie, then several files under
>>   "/proc/<pid>" won't work, though using "/proc/<pid>/task/<tid>" would.
>>   (try poking at leader-exit.exp a bit.)
>>   The latter path form is also generally better for being robust in
>>   the case TID exits and is reused in another process, much like
>>   tkill vs tgkill.
> 
> I thought that the process exited whenever the main thread exits, that's
> not the case?  I guess not if there's a test for it...

Nope.  If you call "exit", then yes.  The kernel kills the whole thread
group in response to that system call.  If the leader does
pthread_exit, then no, the thread group stays around until all children
exit too.  The kernel won't report the main thread's exit status (i.e.,
we can't reap that zombie, and we'd hang if we tried a blocking waitpid)
until all the children are reaped first.  That's why we have
linux-nat.c:check_zombie_leaders (and the equivalent in gdbserver).

>> So if possible to switch those spots too, I'd recommend/prefer it.
> 
> Ok, I'll just replace ptid_get_pid with get_ptrace_pid* in this patch

Since this is linux-specific code, you should be able to use
ptid_get_lwp directly.

> and look at using /proc/<pid>/task/<tid> after.  When doing the latter,
> do I still have to consider cases where ptid is a single-process/thread
> ptid (lwp == 0)?  From my experience, there's always a lwp on Linux, but
> perhaps there are some setups I don't know about with which it can happen?

Right, on Linux there's always an lwp.  Before NPTL, the 
/proc/<pid>/task/<tid> path didn't exist at all, but we no longer
support LinuxThreads.

Thanks,
Pedro Alves


  reply	other threads:[~2017-03-22  1:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-21 22:18 Simon Marchi
2017-03-21 23:58 ` Pedro Alves
2017-03-22  0:42   ` Simon Marchi
2017-03-22  1:01     ` Pedro Alves [this message]
2017-03-22  1:13       ` Pedro Alves
2017-03-22  1:22       ` Simon Marchi
2017-03-22  3:03         ` [PATCH v2] " Simon Marchi
2017-03-22 11:28           ` 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=cf900897-3e74-aa71-32b8-4f6c96e6a0a6@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simon.marchi@ericsson.com \
    --cc=simon.marchi@polymtl.ca \
    /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