Re: [PATCH v1 2/2] gdb: rely on the first non-exited thread TPID when reading Linux procfs files

Matthieu Longo <[email protected]>
Newsgroups gmane.comp.gdb.patches
Message-ID <[email protected]>
On 24/08/2026 17:25, Matthieu Longo wrote:
> On 24/08/2026 16:29, Matthieu Longo wrote:
>> On 20/08/2026 16:48, Simon Marchi wrote:
>>> On 7/28/26 10:33 AM, Matthieu Longo wrote:
>>>> +/* Return a PTID that identifies the current process and can be used to
>>>> +   access procfs safely.
>>>> +
>>>> +   The returned PTID is that of the thread-group leader whenever it is
>>>> +   still alive.  If the leader has already exited, the PTID of the first
>>>> +   non-exited thread in the current inferior is returned instead.
>>>> +   This ensures that the returned PTID always refers to a live thread
>>>> +   whose procfs entries are present and populated.  */
>>>> +static ptid_t
>>>> +get_process_reference_ptid (bool verbose = false)
>>>> +{
>>>> +  /* Get the current thread.  */
>>>> +  thread_info *thr = inferior_thread ();
>>>> +
>>>> +  /* Construct the PTID of the thread-group leader.  On Linux,
>>>> +     the leader's LWP ID is equal to the process ID.  */
>>>> +  ptid_t leader_ptid (thr->ptid.pid (), thr->ptid.pid ());
>>>> +
>>>> +  /* Use the thread-group leader if it is still alive.  Otherwise, use
>>>> +     the first thread that has not exited.  */
>>>> +  thread_info *leader_thr
>>>> +    = current_inferior ()->find_thread (leader_ptid);
>>>> +  ptid_t ptid = (leader_thr == nullptr
>>>> +		 ? current_inferior ()->first_non_exited_thread ()
>>>> +		 : leader_ptid);
>>>> +
>>>> +  if (!verbose)
>>>> +    return ptid;
>>>> +
>>>> +  if (leader_thr != nullptr)
>>>> +    gdb_printf (_("process %d\n"), leader_ptid.pid ());
>>>> +  else
>>>> +    gdb_printf (_("process %d [Note: information where gathered from LWP %ld " \
>>>> +		  "as the thread-group leader (LWP=%ld) already exited.]\n"),
>>>> +		ptid.pid (), ptid.lwp (), leader_ptid.lwp ());
>>>
>>> I don't think the printfs should be part of this getter function.  Move
>>> it to a separate function called by whoever needs it.  Or just inline
>>> it, it looks like there is just a single caller that needs it
>>> (linux_info_proc).
>>>
>>
>> The idea is to inform the user if a fallback occurs.
>> Now, if I move the printing to another function, I don't have the fetched information anymore, and
>> cannot figure out easily if a fallback happened and using which thread.
>>
>> It is ugly but I could not find better.
>> Do you have a better approach ?
>>> Matthieu
> 
> There is actually a way to figure it out by comparing ptid.pid () and ptid.lwp ().
> 
> Sent r2 addressing your comment.
> https://inbox.sourceware.org/gdb-patches/[email protected]/T/#u
> 
> Matthieu

Sorry, I mistakenly removed you from CC by not clicking the "reply all" button.

Matthieu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.