Hi Ulrich and Simon, Please find attached a new patch on this. [See: 0001-Enable-multi-process-debugging-for-AIX.patch] I have addressed your issue of having a fork () events from other threads. There is one difference between AIX and the way freebsd can handle. freebsd gets the parent child relationship via a structure which has this info. This is obtained using LWP_INFO option in the ptrace () call. However, in AIX we do not have the same luxury of LWP_INFO. Here is how it works. A fork () event can be caused by the debugee only. Once the child is obtained, we know for a fact that either it is detached or stopped in the instruction where the parent was before fork () event. The child is not going to generate any fork event. Hence only this debugee which the parent will be able to fork again. As far as multiple thread fork is concerned, I have taken care of it in the code by a fact that a parent process will be in the inferior list. Coming to the W_SFWTED, this also is taken care. Kindly see the did_aix_inferior_fork () function. I have kept an assertion as well just in case I get some other event apart from fork () comes in while I figure out the parent child relationship. Ideally, I shouldn't get any other event in AIX. Kindly let me know what is your feeback on this. If its good kindly push the same. Have a nice day ahead. Thanks and regards, Aditya. ________________________________ From: Ulrich Weigand Sent: 22 August 2022 18:55 To: simark@simark.ca ; Aditya Kamath1 ; gdb-patches@sourceware.org Cc: Sangamesh Mallayya Subject: Re: [PATCH] Enable multi process debugging for AIX Aditya Kamath1 wrote: >Enable PT_MULTI option in ptrace () call along with the process ID >parameter and the data parameter enabled. Usually one enables multi >process debugging for all the process debugged in post_startup_inferior >() function like in the Linux world. >On a fork () event either the child can report a wait event first or >the parent. >A status of 57e in hexadecimal or 1406 in decimal is returned from the >waitpid () with the process ID. This can be used to detect a fork () >event. >Since the child process will not have an inferior, we check with the >find_inferior_pid () to see if the child reports first. If it is the >next wait event is generated by the parent in AIX. This is how we >absorb the parent and child event to fetch their process ID. >The vice versa of the above can be done if the parent process reports a >fork () event first. >Once it is done we tell the gdb core that we forked with ourstatus by passing the child ptid. Simon already commented on this in his initial review, and I think this is still not completely addressed. Most importantly, your code simply assumes that it is guaranteed that the two wait events for parent and child will arrive immediately after one another, and the only uncertain issue is the sequence between the two. Is is actually guaranteed that this is the case? Or could we also have random other wait events (e.g. from other threads / processes) that can be reported in between? In that case, your implementation now introduces a race condition where some event might get lost. A proper fix might then have to be more involved, e.g. by storing those event on some sort of "pending list" and only report a fork event to common code once both sides have checked in, similar to the FreeBSD approach Simon already pointed out to you. As to this: +# define AIX_FORK_EVENT 0x57e It would be much preferable to use the official names for these constants. For example, the document you mention here: >More about this can be read in the document >https://www.ibm.com/docs/en/aix/7.2?topic=p-ptrace-ptracex-ptrace64- subroutine talks about: W_SFWTED Process stopped during execution of the fork subroutine. Is this the 0x57e event? If so, we should call it W_SFWTED in GDB as well, and not some made-up name. It would be great if you could find the official names for all the other "magic" constants like 0x7f, 0x17f, 0x137f etc. as well. Bye, Ulrich