From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3403 invoked by alias); 22 Mar 2017 00:42:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 3389 invoked by uid 89); 22 Mar 2017 00:42:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Mar 2017 00:42:28 +0000 Received: by simark.ca (Postfix, from userid 33) id 57CC21E165; Tue, 21 Mar 2017 20:42:27 -0400 (EDT) To: Pedro Alves Subject: Re: [PATCH] Remove lwp -> pid conversion in linux_nat_xfer_partial X-PHP-Originating-Script: 33:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 22 Mar 2017 00:42:00 -0000 From: Simon Marchi Cc: Simon Marchi , gdb-patches@sourceware.org In-Reply-To: References: <20170321221744.20567-1-simon.marchi@ericsson.com> Message-ID: <3da10b16ca20d771c39f07a73235c7d3@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.2.4 X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00383.txt.bz2 On 2017-03-21 19:58, Pedro Alves wrote: > Yeah... The stuffing of lwpids in the inferior_pid integer global was > clearly > a hack. But when later GDB grew the "ptid" structure, this shuffling > made some sense -- way back then, when we had LinuxThreads instead of > NTPL, the > kernel didn't really have any concept of "threads" or "lwps". Threads > were really each a heavy weight process. So in that sense, in the > abstract, > it made some sense to have inf-ptrace.c only ever think about > processes. But, > over the years we've been running into issues with that, and over time > the inf-ptrace.c layer as been adjusted to understand these ptids. > Commit 90ad5e1d4f34d0 > ("Linux/ptrace: don't convert ptids when asking inf-ptrace layer to > resume LWP") > is one that comes to mind. You've running into some left overs of a > long > slow conversion... Ok, thanks for the history bits. >> 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/", 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// may not work if the 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/" won't work, though using "/proc//task/" > 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... > 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 and look at using /proc//task/ 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? * using get_ptrace_pid is an abuse of terminology, since we're not using ptrace, but it does what we want. Thanks, Simon