Simon Marchi, le sam. 30 mai 2020 12:08:53 -0400, a ecrit: > 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.
Ok, I see. thread_change_ptid is however also called from inf_validate_procs, called from inf_update_procs, called from i386_gnu_dr_set_control, referenced from the x86 backend x86_dr_low.set_control = i386_gnu_dr_set_control; For simplicity I'll keep gnu_target for now, but also work on cleaning these should-be-static/private functions. Samuel
