From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84933 invoked by alias); 21 Mar 2017 23:58:26 -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 84923 invoked by uid 89); 21 Mar 2017 23:58:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=grew X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Mar 2017 23:58:24 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A5FFA12B24; Tue, 21 Mar 2017 23:58:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A5FFA12B24 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=palves@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A5FFA12B24 Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5979E5C892; Tue, 21 Mar 2017 23:58:24 +0000 (UTC) Subject: Re: [PATCH] Remove lwp -> pid conversion in linux_nat_xfer_partial To: Simon Marchi , gdb-patches@sourceware.org References: <20170321221744.20567-1-simon.marchi@ericsson.com> Cc: Simon Marchi From: Pedro Alves Message-ID: Date: Tue, 21 Mar 2017 23:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170321221744.20567-1-simon.marchi@ericsson.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00381.txt.bz2 On 03/21/2017 10:17 PM, Simon Marchi wrote: > From: Simon Marchi > > When inferior_ptid represents a lwp, linux_nat_xfer_partial converts it > to a ptid with only the pid field set. For example, if > inferior_ptid is: > > { .pid = 1234, .lwp = 1235 } > > it will change it to: > > { .pid = 1235, .lwp = 0 } > > This is presumably because not all implementations of to_xfer_partial > that might be called down the line know how to handle a ptid with a lwp. > From what I found, it's been like this for a long long time, I traced > the original implementation at least to this commit (1999) > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/lin-thread.c;h=2f255c0e54a0387f1b7994c0bf808f4320b9b054;hb=ed9a39e#l1241 > > It looks like a hack to me, I think it's simpler if we just make all > implementations handle ptids correctly. The only place I found that > needed fixing is inf_ptrace_xfer_partial. 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... > > 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. So if possible to switch those spots too, I'd recommend/prefer it. > > The testsuite found no regression on native amd64 linux. > > gdb/ChangeLog: > > * inf-ptrace.c (inf_ptrace_xfer_partial): Get pid from ptid > using get_ptrace_pid. > * linux-nat.c (linux_nat_xfer_partial): Don't set/restore > inferior_ptid. Looks good to me. Thanks, Pedro Alves