[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCHv2 6/7] hurd: add gnu_target pointer to fix thread API calls

From: Simon Marchi
Subject: Re: [PATCHv2 6/7] hurd: add gnu_target pointer to fix thread API calls
Date: Sat, 30 May 2020 12:08:53 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1

On 2020-05-30 11:53 a.m., Samuel Thibault wrote:
> Simon Marchi, le sam. 30 mai 2020 10:57:42 -0400, a ecrit:
>>> @@ -1106,12 +1109,12 @@ inf_validate_procs (struct inf *inf)
>>>         if (inferior_ptid == ptid_t (inf->pid))
>>>           /* This is the first time we're hearing about thread
>>>              ids, after a fork-child.  */
>>> -         thread_change_ptid (inferior_ptid, ptid);
>>> +         thread_change_ptid (gnu_target, inferior_ptid, ptid);
>> I think it would have been more straightforward and clean to use 
>> `inf->process_target ()`
>> (assuming it's the correct thing to do), given that you have access to the 
>> appropriate
>> inferior everywhere you made changes.
> I didn't see a way to access the inferior here (inf is a
> gnu-nat.c-specific structure with no link to struct inferior)

Ah I see.  Well, I didn't check all code paths, but for example, for the one 
that goes:

- gnu_nat_target::attach
- inf_attach
- inf_startup
- inf_set_pid

A solution would be to make all these inf_* functions to be private methods of 
gnu_nat_target class.  They would then pass `this` as the 
process_stratum_target.  A
bit like what was done in commit

  gdb: fix darwin-nat.c build / adapt to multi-target

Even if you are not doing this, a good cleanup would be to make all those 
(like inf_attach) static.  They are only used in gnu-nat.c, but are exported.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]