From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127262 invoked by alias); 22 Mar 2017 01:01:02 -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 126869 invoked by uid 89); 22 Mar 2017 01:01:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=reap, Hx-languages-length:2281, nope X-HELO: mail-wr0-f174.google.com Received: from mail-wr0-f174.google.com (HELO mail-wr0-f174.google.com) (209.85.128.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 22 Mar 2017 01:00:59 +0000 Received: by mail-wr0-f174.google.com with SMTP id g10so121684658wrg.2 for ; Tue, 21 Mar 2017 18:01:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=ThjsMnd1ED3qNZZEzf+0mQ57FbS3E/TUJ/uckKnJ3g4=; b=lbVv+8p17c0PYdj1J0MGcOQx1kKMpGvUHjyZ/XRQL5gYaw/ITZHm8vLtexcfoKX+kI xeBY8L0ZbXYt6Jmc6brJ2pjYwv325vva6Kq7xcf5JN3159zj0PDiRRhhdIOMrRc9HOjG fpD7osV+QYgZ4umW37pCxRQhsdqBTdD4PlmCTdAQSOaVU/eNVRpzimbeIFTdFlvWJa+g Lo+GGzfDDmUjZhlXqPd1DYCYDahd6/YcJnJgiJPBGHIEosvZ9pOTCiEtxSsXbpGUZSUD cyAXdd5kZqlheWj3BXXS+e0ZSmYTlcuAFnSskWqOsAqtF2ETqoMovmWFGWaI9ctKjcvD RUZQ== X-Gm-Message-State: AFeK/H0zchYAaWd7ArIbnA5R63sg90SU0Zwa9AnxRoFgv+JgK1c81pcRx354SUJlKLEgau5N X-Received: by 10.223.155.147 with SMTP id d19mr28679135wrc.99.1490144458748; Tue, 21 Mar 2017 18:00:58 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id b58sm26931518wra.47.2017.03.21.18.00.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 18:00:57 -0700 (PDT) Subject: Re: [PATCH] Remove lwp -> pid conversion in linux_nat_xfer_partial To: Simon Marchi References: <20170321221744.20567-1-simon.marchi@ericsson.com> <3da10b16ca20d771c39f07a73235c7d3@polymtl.ca> Cc: Simon Marchi , gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Wed, 22 Mar 2017 01:01: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: <3da10b16ca20d771c39f07a73235c7d3@polymtl.ca> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00384.txt.bz2 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/", 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... 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//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? Right, on Linux there's always an lwp. Before NPTL, the /proc//task/ path didn't exist at all, but we no longer support LinuxThreads. Thanks, Pedro Alves