Hi Ulrich, Please find attached the new patch. See 0001-Fix-Multi-thread-debug-bug-fix-in-AIX.patch .. >So I think instead of adding a "priv" struct to that GDB thread >identifying the main process, the sync_threadlists routine should >actually just delete it (or replace it with the actual first thread, >whatever is easier). I have chosen not to add the first main thread as new thread. Instead, we carry on with main process thread itself adding private data to it. Kindly see the first if condition. I observed this with the linux folks where in their output as you mentioned do not add any new threads the first time on recognition of multi thread debugee for the main process. >Looking at the code, there already seems to be a place where >sync_threadlists deletes GDB threads that do not match onto >and of the threads reported by the AIX thread library - can >you verify why this doesn't trigger here? So that is when there is a thread that exits, and it will reflect in pthread library thread buffer but not in the GDB thread buffer. In order to keep both of them in sync we delete extra one's in GDB thread library buffer to maintain sync in both of them. It is not going to hit to delete extra threads representing the same thread be it for the main process or anything else. pi == pcount will happen only in the thread exit case where pthread buf threads are deleted as it will immediately reflect but in GDB thread buf we need to take care of the same by deleting the exited threads. A couple of things I want to inform you is that the way the second for loop is executing is not correct from here on to sync both the buffer lists [pthread and GDB thread]. Since we are now not adding multiple threads for the same process main thread one representing the GDB thread and the other by the pthread those conditions and indices like pi and gi will fail. Now there has not pcount - 1 threads in the GDB thread buffer always. Condition 2 and 3 in the patch take care of them for addition and deletion of threads. Attaching a sample output with source code. Let me know what you think and if any case that I may have missed out. If it is okay, then kindly push this patch. Have a nice day ahead. Thanks, Regards, Aditya. ------------------------------------------------------------------ Consider the program below:- [ Program Credits:- GDB test case continue-pending-status.c] #include #include #include #include #include pthread_barrier_t barrier; #define NUM_THREADS 2 void * thread_function (void *arg) { pthread_barrier_wait (&barrier); while (1); /* break here */ } int main (void) { int i; alarm (300); pthread_barrier_init (&barrier, NULL, NUM_THREADS); for (i = 0; i < NUM_THREADS; i++) { pthread_t thread; int res; res = pthread_create (&thread, NULL, thread_function, NULL); assert (res == 0); } while (1) sleep (1); return 0; } Output after patch:- Reading symbols from /home/XYZ/gdb_tests/continue-pending-status... (gdb) r Starting program: /home/XYZ/gdb_tests/continue-pending-status ^C[New Thread 258] [New Thread 515] Thread 1 received signal SIGINT, Interrupt. 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) (gdb) info threads Id Target Id Frame * 1 process 26149278 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) 2 Thread 258 (tid 24445361, running) thread_function (arg=0x0) at continue-pending-status.c:36 3 Thread 515 (tid 16187681, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) 0x0) at continue-pending-status.c:36 (gdb) ________________________________ From: Ulrich Weigand Sent: 08 November 2022 17:47 To: simark@simark.ca ; Aditya Kamath1 ; gdb-patches@sourceware.org Cc: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Aditya Kamath1 wrote: >>You should find out why the "priv" field isn't >>set up correctly, and fix whatever was going >>wrong there. (I believe this should have been >>done in sync_threadlists.) > >You were right about this. What is happening is the main process >and the thread representing it are treated as two separate threads >by the libpthread library. Main process had no private data set >whereas the thread representing it had. Usually, both of them >should have it and their private data must be the same. I see. I agree this is the root cause of the issue, but the fix doesn't look quite right to me. You should not even *have* the duplicate GDB thread in the first place. >(gdb) info threads > Id Target Id Frame >* 1 process 12059046 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) > 2 Thread 1 (tid 39125487, running) 0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o) > 3 Thread 258 (tid 23396809, running) thread_function (arg=0x0) at continue-pending-status.c:36 > 4 Thread 515 (tid 36503883, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.) This is not how GDB threads are handled on any other platform. While you do have a single dummy thread representing the process if it is *non-threaded*, as soon as the process is recognized as multi-threaded, you will only see a single GDB thread per target thread, and no separate "thread" for the whole process. So I think instead of adding a "priv" struct to that GDB thread identifying the main process, the sync_threadlists routine should actually just delete it (or replace it with the actual first thread, whatever is easier). Looking at the code, there already seems to be a place where sync_threadlists deletes GDB threads that do not match onto and of the threads reported by the AIX thread library - can you verify why this doesn't trigger here? Bye, Ulrich