From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id BF1323858D35 for ; Mon, 8 Jan 2024 15:50:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BF1323858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BF1323858D35 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704729010; cv=none; b=ilTYLpewe1T5LKr6hoAtC5bbgpOcyJat/NHpN+645FVd1ezkbYcWLrTOS/cTC9efn+g+pxrDLlJ8SmIga7ihBF0/x7J2w23Yn6SlQ5/ArXEme3guDwTeXK1UBogn6YUVy1l+h0L8KpIH9Wj0zZmqy3EiUqRIi54A+BmWN734yGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704729010; c=relaxed/simple; bh=D7k01B73dmzJ7c2kvEH5AgLllhf+B3xLW/6Q/yeM4OU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=tNZCCWvgrSDe+f4SKr3Rh9B4pe6+rAnMpqW38OUwiDj+n2ZGmPqF+AIhXctAEbwp7A3I6kJ84p1qFn4FfjjZkavoGSNw8F9DV3WO/VWLVT4jpt6we/FRIObkksgPvlLj5r+XBvHPOZh6AgiDIlCIKsl443lj/AuPGfadadcnssk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1704729008; bh=D7k01B73dmzJ7c2kvEH5AgLllhf+B3xLW/6Q/yeM4OU=; h=Date:Subject:To:References:From:In-Reply-To:From; b=A7X3e5luZW+/Qhx1Ur5ApZFStj3hXMTuhj2oQNuXKBq5LnepolqaKY3JSg+6AY3N8 uxObMXdaVowXHt6qSAiM55ll7XFD2ioINZY9U78CKplyFiKa/5O7AGPDkaEEM+di5/ YsgYUruVGKbMmlXiUfr8pKrxlEZ1+oCgN4CqGbN0= Received: from [10.0.0.11] (modemcable238.237-201-24.mc.videotron.ca [24.201.237.238]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 0996A1E0B9; Mon, 8 Jan 2024 10:50:08 -0500 (EST) Message-ID: <10c3cce7-1253-45a6-9443-ea673a20bc5d@simark.ca> Date: Mon, 8 Jan 2024 10:50:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Make `linux_info_proc` prefer using the LWP over the PID To: Matheus Branco Borella , gdb-patches@sourceware.org References: <20240106024512.14270-1-dark.ryu.550@gmail.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20240106024512.14270-1-dark.ryu.550@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-10.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2024-01-05 21:45, Matheus Branco Borella wrote: > Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31207 We use `Bug:` for these. Also, move it at the end of the commit message, like standard git trailers (https://git-scm.com/docs/git-interpret-trailers). > Normally, `linux_info_proc` would use the PID to determine which subfolder in > `/proc` to read information from. While this is usually fine, it breaks down > after the main thread exits, at which point the information in `/proc/$pid` > becomes become unreliable, if it is available at all. While it is the case > that most programs terminate after their main thread exits, some may continue > running from detached threads, in which case `info proc` will start misbehaving. > > This patch addresses this by making it so that the LWP - the Lightweight Process > ID, that, in the case of GNU/Linux is the number of the process backing up the > thread[1] - is prefered over the PID. By doing this, `linux_info_proc` will > always access valid procfs information, even after the main thread exits. > > [1]: https://man7.org/linux/man-pages/man2/clone.2.html > --- > gdb/linux-tdep.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c > index 82e8bc3db3c..2c91e298d45 100644 > --- a/gdb/linux-tdep.c > +++ b/gdb/linux-tdep.c > @@ -840,7 +840,14 @@ linux_info_proc (struct gdbarch *gdbarch, const char *args, > if (current_inferior ()->fake_pid_p) > error (_("Can't determine the current process's PID: you must name one.")); > > - pid = current_inferior ()->pid; > + /* Seeing as, when the main thread exits, the information in /proc/$pid > + * becomes unreliable, we should prefer using the current TID, whenever > + * possible. */ > + pid = inferior_ptid.lwp (); > + > + /* And fall back to the actual PID only when the TID is not available. */ > + if (pid == 0) > + pid = current_inferior ()->pid; I would suggest trying to use the any_live_thread_of_inferior function to get a non-exited thread. This way, if the current thread has exited, it will find another that should be suitable for reading the proc information. I can imagine another case where thing would go wrong. There might be threads which have exited, but for which we have not processed the "exited" event yet. The exited state will not yet be reflected in the thread_info structure, so we might pick it thinking it's a live thread. But I would ignore that problem for now, what you propose is already a good improvement over the current state. Simon