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

[Simon Marchi <simark@simark.ca>]

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 the
gnu_nat_target class.  They would then pass `this` as the process_stratum_target.  A
bit like what was done in commit

  e7eee665a1524cc4569d0c2f5c9d4aa2be64c9e8
  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 functions
(like inf_attach) static.  They are only used in gnu-nat.c, but are exported.

Simon