public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Aditya Kamath1 <Aditya.Kamath1@ibm.com>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	"simark@simark.ca" <simark@simark.ca>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch
Date: Fri, 2 Dec 2022 07:50:21 +0000	[thread overview]
Message-ID: <CH2PR15MB354486F155F5CC97501D056DD6179@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <139ff3da5e35905c963869569bebf280733740c2.camel@de.ibm.com>


[-- Attachment #1.1: Type: text/plain, Size: 18159 bytes --]

Hi Ulrich and community,

Please find attached the new patch [See:- 0001-Fix-multi-thread-debug-bug-in-AIX.patch ]

So now the proposed patch attached in this email works fine for single process and multi process code with detach fork on and off options. Kindly see output 1 and program 1 for single process case and program 2 and outputs 2, 3 and 4 for multi process case [It points out that if a process is a thread, it is a thread. It is highlighted in bold]. The unit test cases run well. Output 4 is following child. It is attached to be sure things work in all cases.  The proposed patch has a pid_to_str () function that helps us. So, when in a multi process case a switch happens between process due to any event the control checks in our rs6000-aix-nat.c for thread or process information from thread_target_id_str () from thread.c file.
This part is now solved.

There are some optimisations for which I need your advice since you are the expert.

So here are my reasons..

>>ourstatus->set_forked (ptid_t (pid));
>>-             return ptid_t (parent_pid);
>>+             return find_the_return_ptid (parent_pid);
>>
>>Kindly note that the control will always not come from aix-thread.c
>>for such events. Hence, we cannot take care of the same there,
>>though it will be a relief if we can do that.

>I'm not sure why it is necessary to handle this in the process layer
>(rs6000-aix-nat.c) instead of the thread layer (aix-thread.c).
>What specifically breaks if you do not have these rs6000-aix-nat.c
>changes?

So, if you observe output 3 or 4, the program first multi threads, I mean thread events are handled first and then the threads fork. So, when this happens, I cannot return ptid_t (parent_pid). If I do so, the GDB core will treat it as a new process and add it in my threadlist as say process 100 despite existence of 'thread 1' representing the same. So, I need to correctly send which thread did the fork () event or which thread of the process is the one who gave birth to a new inferior process [say 2 or 3 in output 3 below], I mean which thread caused the mult process event when the process is mutli threaded. This has to handled here as control from target.c comes directly to rs6000-aix-nat::wait and not through aix-thread.c::wait since fork () is a process event..

>If you *do* need to handle LWPs (kernel thread IDs) in the process
>layer (this can be a reasonable choice, and it done by several other
>native targets), then it should be *consistent*, and *all* LWP handling
>should be in the process layer. In particular, under no circumstances
>does it make sense to duplicate the "find current/signalled thread"
>code in *both* the process any thread layers.

This not straightforward to do. The reason being say our application is pthreaded We need our sync_threadlists() code to detect multiple threads and sync.. We cannot handle this in rs6000-aix-nat.c with the current design of the code.. Let's say child process is multi-threaded things can get complex.. It will require us to move that whole GDB list and Pthread list sync code to rs6000-aix-nat.c code. The essence or most selling product or the USP [Unique Selling Proposition] of aix-thread.c code will be lost.

Let me know what you think of this, and I will modify this patch as per how you guide or suggest.. This is where I wanted to reach out to all of you in the community as I think this might be a code design change needed.


>>[Switching to process 16777620]

>This outputs inferior_ptid ...

Yes, you were right

>>* 1.1  process 16777620  0xd0595fb0 in _p_nsleep ()
>>   from /usr/lib/libpthread.a(shr_xpg5.o)
>>  1.2  process 16777620  0xd0595fb0 in _p_nsleep ()
>>   from /usr/lib/libpthread.a(shr_xpg5.o)
>>  1.3  process 16777620  0xd0595fb0 in _p_nsleep ()
>>   from /usr/lib/libpthread.a(shr_xpg5.o)
>>  2.1  process 8323570   0xd0594fc8 in ?? ()
>>  3.1  process 17957172  0xd0594fc8 in ?? ()

>... and this outputs the ptid values for those threads.

>If it says "process ...", then those ptid values have not
>properly been switched over to the (pid, lwp, tid) format.

>You should verify that the sync_threadlists code handles
>all multi-process cases correctly.  I haven't looked at
>this in detail, but are you sure that here:

>>@@ -841,8 +829,22 @@ sync_threadlists (int pid)
 >>            }
 >>          else if (cmp_result > 0)
 >>            {
>>-             delete_thread (gbuf[gi]);


>you never accidentally switch the *pid* part (if "gptid"
>belows to a different pid than "pptid")?

So, this is not the reason. I have added an assertion here just to be sure. I get what you are thinking. While debugged in depth last two days I realised our pid_to_str is needed in rs6000-aix-nat.c as control comes here in search of it. If it doesn't GDB treats all threads as process. It is the patch. Kindly see it and the outputs [3 and 4 below this email] as well.

>Hmm.  So when "wait" returns, it needs to determine which thread
>triggered the event that caused ptrace to stop.  On Linux, "wait"
>will actually return the LWP of that thread, so it can be directly
>used.  It seems on AIX, "wait" only returns a PID, and you do not
>immediately know which thread caused the event?

>In that case, I can see why you'd have to consider SIGINT as well
>as SIGTRAP. However, it seems to me that even those two are not the
>*only* cases that can cause "wait" to return - doesn't *any* signal
>(potentially) trigger a ptrace intercept (causing wait to return)?

>But that's probably a more general problem, and wouldn't occur in
>this simple test case.

Exactly. So I tried debugging few examples causing a few other signals as mentioned in this document [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=reference-signal-handling]. In AIX we have most of them mentioned in the link. It does not block us from doing things or crashes incase of a segment fault signal [from our debugger code]. Abort also works fine. Let me know what you think.



----------------------------------------------------------------
Program1:- [Credits gdb.threads/continuous-pending.c]


#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <pthread.h>

#include <assert.h>


pthread_barrier_t barrier;


#define NUM_THREADS 3


void *

thread_function (void *arg)

{

  /* This ensures that the breakpoint is only hit after both threads

     are created, so the test can always switch to the non-event

     thread when the breakpoint triggers.  */

  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;

}



----------------------------------------------------------------
Output1:- Single process


Reading symbols from /home/aditya/gdb_tests/continue-pending-status...

(gdb) r

Starting program: /home/aditya/gdb_tests/continue-pending-status

^C[New Thread 258]

[New Thread 515]

[New Thread 772]


Thread 3 received signal SIGINT, Interrupt.

[Switching to Thread 515]

thread_function (arg=0x0)

    at /home/aditya/gdb_tests/continue-pending-status.c:36

36        while (1); /* break here */

(gdb) info threads

  Id   Target Id                          Frame

  1    Thread 1 (tid 24838585, running)   warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


  2    Thread 258 (tid 23134635, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/continue-pending-status.c:36

* 3    Thread 515 (tid 30146867, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/continue-pending-status.c:36

  4    Thread 772 (tid 27853165, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/continue-pending-status.c:36

---------------------------------------------------------------------------------

Program 2:- Multi process Code


#include <stdio.h>

#include <unistd.h>

#include <stdlib.h>

#include <pthread.h>

#include <assert.h>


pthread_barrier_t barrier;


#define NUM_THREADS 2


void *

thread_function (void *arg)

{

  /* This ensures that the breakpoint is only hit after both threads

     are created, so the test can always switch to the non-event

     thread when the breakpoint triggers.  */


  pthread_barrier_wait (&barrier);

  pid_t child;


  child = fork ();

  if (child > 0)

    printf ("I am parent \n");

  else{

    printf (" Iam child \n");

    child = fork ();

    if (child > 0)

      printf ("From child I became a parent \n");

    else

      printf ("I am grandchild \n");

  }

  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 (15);

    break;

  }


  return 0;

}


-------------------------------------------------------------------------

Output 2:- With detach-on-fork on


Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork...

(gdb) r

Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork

[New Thread 258]

[New Thread 515]

[Detaching after fork from child process 8323572]

 Iam child

I am grandchild

From child I became a parent

I am parent

[Detaching after fork from child process 11665884]

 Iam child

I am grandchild

From child I became a parent

I am parent

^C

Thread 2 received signal SIGINT, Interrupt.

[Switching to Thread 258]

thread_function (arg=0x0)

    at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32

32        while (1); /* break here */

(gdb) info threads

  Id   Target Id                          Frame

  1    Thread 1 (tid 27263269, running)   warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


* 2    Thread 258 (tid 28705075, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32

  3    Thread 515 (tid 27853169, running) thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32


-------------------------------------------------------------------------

Output 3:- With detach-on-fork off


Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork...

(gdb) set detach-on-fork off

(gdb) r

Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork

[New Thread 258]

[New Thread 515]

[New inferior 2 (Process 15466928)]

[New inferior 3 (Process 13894048)]

I am parent

I am parent

^C

Thread 1.1 received signal SIGINT, Interrupt.

[Switching to Thread 1]

0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o)

(gdb) info threads

  Id   Target Id         Frame

* 1.1  Thread 1          0xd0595fb0 in _p_nsleep ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  1.2  Thread 258        0xd0595fb0 in _p_nsleep ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  1.3  Thread 515        0xd0595fb0 in _p_nsleep ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  2.1  Process 15466928  0xd0594fc8 in ?? ()

  3.1  Process 13894048  0xd0594fc8 in ?? ()

--------------------------------------------------

Output 4:- detach fork off and following child


Reading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork...

(gdb) set detach-on-fork off

(gdb) set follow-fork-mode child

(gdb) r

Starting program: /home/aditya/gdb_tests/ultimate-multi-thread-fork

[New Thread 258]

[New Thread 515]

[Attaching after Thread 515 fork to child Process 13894050]

[New inferior 2 (Process 13894050)]

 Iam child

[Attaching after Process 13894050 fork to child Process 11010474]

[New inferior 3 (Process 11010474)]

I am grandchild

^CReading symbols from /home/aditya/gdb_tests/ultimate-multi-thread-fork...


Thread 3.1 received signal SIGINT, Interrupt.

[Switching to Process 11010474]

thread_function (arg=0x0)

    at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32

32        while (1); /* break here */

(gdb) info threads

  Id   Target Id         Frame

  1.1  Thread 1          0xd0594fc8 in _sigsetmask ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  1.2  Thread 258        0xd0594fc8 in _sigsetmask ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  1.3  Thread 515        0xd0594fc8 in _sigsetmask ()

   from /usr/lib/libpthread.a(shr_xpg5.o)

  2.1  Process 13894050  0xd0594fc8 in ?? ()

* 3.1  Process 11010474  thread_function (arg=warning: (Internal error: pc 0x0 in read in psymtab, but not in symtab.)


0x0)

    at /home/aditya/gdb_tests/ultimate-multi-thread-fork.c:32


________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 30 November 2022 20:27
To: simark@simark.ca <simark@simark.ca>; Aditya Kamath1 <Aditya.Kamath1@ibm.com>; gdb-patches@sourceware.org <gdb-patches@sourceware.org>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch

Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:

>Before we had an extra thread 'process 100' apart from 'thread 1'.
>So, in case someone interrupted a thread with ctrl+c.. In the
>pd_update () even if we don't have thread who signalled this interrupt
>when we return ptid_t (pid) it was fine. But now with no 'process 100'
>and only 'thread 1', we need to take care of interrupt as well,
>otherwise GDB core will take ptid_t(100) as a new process.
>So the change
>+      if (thrinf.ti_cursig == SIGTRAP || thrinf.ti_cursig == SIGINT)

Hmm.  So when "wait" returns, it needs to determine which thread
triggered the event that caused ptrace to stop.  On Linux, "wait"
will actually return the LWP of that thread, so it can be directly
used.  It seems on AIX, "wait" only returns a PID, and you do not
immediately know which thread caused the event?

In that case, I can see why you'd have to consider SIGINT as well
as SIGTRAP. However, it seems to me that even those two are not the
*only* cases that can cause "wait" to return - doesn't *any* signal
(potentially) trigger a ptrace intercept (causing wait to return)?

But that's probably a more general problem, and wouldn't occur in
this simple test case.

>In this case if we return a ptid_t (pid) then gdb core treats it
>as a new process since our parent thread is pthreaded GDB core
>only knows threads like ptid_t (pid, tid, pthid) and not
>ptid_t (pid). In order to avoid this, the proposed patch uses a
>function call find_the_return_ptid () to figure out the same.
>The changes like below are for this reason.
>
>ourstatus->set_forked (ptid_t (pid));
>-             return ptid_t (parent_pid);
>+             return find_the_return_ptid (parent_pid);
>
>Kindly note that the control will always not come from aix-thread.c
>for such events. Hence, we cannot take care of the same there,
>though it will be a relief if we can do that.

I'm not sure why it is necessary to handle this in the process layer
(rs6000-aix-nat.c) instead of the thread layer (aix-thread.c).
What specifically breaks if you do not have these rs6000-aix-nat.c
changes?

If you *do* need to handle LWPs (kernel thread IDs) in the process
layer (this can be a reasonable choice, and it done by several other
native targets), then it should be *consistent*, and *all* LWP handling
should be in the process layer. In particular, under no circumstances
does it make sense to duplicate the "find current/signalled thread"
code in *both* the process any thread layers.

>[Switching to process 16777620]

This outputs inferior_ptid ...

>0xd0595fb0 in _p_nsleep () from /usr/lib/libpthread.a(shr_xpg5.o)
>(gdb) info threads
>  Id   Target Id         Frame
>* 1.1  process 16777620  0xd0595fb0 in _p_nsleep ()
>   from /usr/lib/libpthread.a(shr_xpg5.o)
>  1.2  process 16777620  0xd0595fb0 in _p_nsleep ()
>   from /usr/lib/libpthread.a(shr_xpg5.o)
>  1.3  process 16777620  0xd0595fb0 in _p_nsleep ()
>   from /usr/lib/libpthread.a(shr_xpg5.o)
>  2.1  process 8323570   0xd0594fc8 in ?? ()
>  3.1  process 17957172  0xd0594fc8 in ?? ()

... and this outputs the ptid values for those threads.

If it says "process ...", then those ptid values have not
properly been switched over to the (pid, lwp, tid) format.

You should verify that the sync_threadlists code handles
all multi-process cases correctly.  I haven't looked at
this in detail, but are you sure that here:

@@ -841,8 +829,22 @@ sync_threadlists (int pid)
             }
           else if (cmp_result > 0)
             {
-             delete_thread (gbuf[gi]);
-             gi++;
+             if (gptid.is_pid ())
+               {
+                 thread_change_ptid (proc_target, gptid, pptid);

you never accidentally switch the *pid* part (if "gptid"
belows to a different pid than "pptid")?

Bye,
Ulrich


[-- Attachment #2: 0001-Fix-multi-thread-debug-bug-in-AIX.patch --]
[-- Type: application/octet-stream, Size: 8565 bytes --]

From f2ae16f2f392919811400ac1f1c83a1e76ec02df Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Fri, 2 Dec 2022 00:59:55 -0600
Subject: [PATCH] Fix multi-thread debug bug in AIX

---
 gdb/aix-thread.c     | 65 +++++++++++++++++++++----------------------
 gdb/rs6000-aix-nat.c | 66 ++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 95 insertions(+), 36 deletions(-)

diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c
index e556c153576..45e0d9c7ae8 100644
--- a/gdb/aix-thread.c
+++ b/gdb/aix-thread.c
@@ -508,14 +508,13 @@ pdc_read_data (pthdb_user_t user_current_pid, void *buf,
   /* This is needed to eliminate the dependency of current thread
      which is null so that thread reads the correct target memory.  */
   {
-    scoped_restore_current_thread restore_current_thread;
+    scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid);
     /* Before the first inferior is added, we pass inferior_ptid.pid ()
        from pd_enable () which is 0.  There is no need to switch threads
        during first initialisation.  In the rest of the callbacks the
        current thread needs to be correct.  */
     if (user_current_pid != 0)
-      switch_to_thread (current_inferior ()->process_target (),
-			ptid_t (user_current_pid));
+      inferior_ptid = ptid_t (user_current_pid);
     status = target_read_memory (addr, (gdb_byte *) buf, len);
   }
   ret = status == 0 ? PDC_SUCCESS : PDC_FAILURE;
@@ -639,36 +638,24 @@ pcmp (const void *p1v, const void *p2v)
   return p1->pthid < p2->pthid ? -1 : p1->pthid > p2->pthid;
 }
 
-/* iterate_over_threads() callback for counting GDB threads.
+/* iterate_over_threads() callback for counting GDB threads.  */
 
-   Do not count the main thread (whose tid is zero).  This matches
-   the list of threads provided by the pthreaddebug library, which
-   does not include that main thread either, and thus allows us
-   to compare the two lists.  */
 
 static int
 giter_count (struct thread_info *thread, void *countp)
 {
-  if (PD_TID (thread->ptid))
-    (*(int *) countp)++;
+  (*(int *) countp)++;
   return 0;
 }
 
-/* iterate_over_threads() callback for accumulating GDB thread pids.
-
-   Do not include the main thread (whose tid is zero).  This matches
-   the list of threads provided by the pthreaddebug library, which
-   does not include that main thread either, and thus allows us
-   to compare the two lists.  */
+/* iterate_over_threads() callback for accumulating GDB thread pids.  */
 
 static int
 giter_accum (struct thread_info *thread, void *bufp)
 {
-  if (PD_TID (thread->ptid))
-    {
-      **(struct thread_info ***) bufp = thread;
-      (*(struct thread_info ***) bufp)++;
-    }
+  **(struct thread_info ***) bufp = thread;
+  (*(struct thread_info ***) bufp)++;
+    
   return 0;
 }
 
@@ -704,7 +691,7 @@ gcmp (const void *t1v, const void *t2v)
 }
 
 /* Search through the list of all kernel threads for the thread
-   that has stopped on a SIGTRAP signal, and return its TID.
+   that has stopped on a SIGTRAP or SIGINT signal, and return its TID.
    Return 0 if none found.  */
 
 static pthdb_tid_t
@@ -719,7 +706,7 @@ get_signaled_thread (int pid)
 		    sizeof (thrinf), &ktid, 1) != 1)
 	break;
 
-      if (thrinf.ti_cursig == SIGTRAP)
+      if (thrinf.ti_cursig == SIGTRAP || thrinf.ti_cursig == SIGINT)
 	return thrinf.ti_tid;
     }
 
@@ -750,6 +737,9 @@ sync_threadlists (int pid)
   pthdb_pthread_t pdtid;
   pthread_t pthid;
   pthdb_tid_t tid;
+  process_stratum_target *proc_target
+	= current_inferior ()->process_target ();
+  thread_info *tp;
 
   /* Accumulate an array of libpthdebug threads sorted by pthread id.  */
 
@@ -810,10 +800,8 @@ sync_threadlists (int pid)
 	  priv->pdtid = pbuf[pi].pdtid;
 	  priv->tid = pbuf[pi].tid;
 
-	  process_stratum_target *proc_target
-	    = current_inferior ()->process_target ();
 	  thread = add_thread_with_info (proc_target,
-					 ptid_t (pid, 0, pbuf[pi].pthid),
+					 ptid_t (pid, pbuf[pi].tid, pbuf[pi].pthid),
 					 priv);
 
 	  pi++;
@@ -823,7 +811,7 @@ sync_threadlists (int pid)
 	  ptid_t pptid, gptid;
 	  int cmp_result;
 
-	  pptid = ptid_t (pid, 0, pbuf[pi].pthid);
+	  pptid = ptid_t (pid, pbuf[pi].tid, pbuf[pi].pthid);
 	  gptid = gbuf[gi]->ptid;
 	  pdtid = pbuf[pi].pdtid;
 	  tid = pbuf[pi].tid;
@@ -841,8 +829,23 @@ sync_threadlists (int pid)
 	    }
 	  else if (cmp_result > 0)
 	    {
-	      delete_thread (gbuf[gi]);
-	      gi++;
+	      if (gptid.is_pid ())
+		{
+		  gdb_assert (gptid.pid () == pptid.pid ());
+		  thread_change_ptid (proc_target, gptid, pptid);
+		  aix_thread_info *priv = new aix_thread_info;
+		  priv->pdtid = pbuf[pi].pdtid;
+		  priv->tid = pbuf[pi].tid;
+		  tp = find_thread_ptid (proc_target, pptid);
+		  tp->priv.reset (priv);
+		  pi++;
+		  gi++;
+		}
+	      else
+		{
+		  delete_thread (gbuf[gi]);
+		  gi++;
+		}
 	    }
 	  else
 	    {
@@ -1091,10 +1094,6 @@ aix_thread_target::wait (ptid_t ptid, struct target_waitstatus *status,
   if (ptid.pid () == -1)
     return ptid_t (-1);
 
-  /* The target beneath does not deal with threads, so it should only return
-     pid-only ptids.  */
-  gdb_assert (ptid.is_pid ());
-
   /* Check whether libpthdebug might be ready to be initialized.  */
   if (!pd_active && status->kind () == TARGET_WAITKIND_STOPPED
       && status->sig () == GDB_SIGNAL_TRAP)
diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c
index 2ac1f6e70b6..e48580f1b96 100644
--- a/gdb/rs6000-aix-nat.c
+++ b/gdb/rs6000-aix-nat.c
@@ -99,6 +99,8 @@ class rs6000_nat_target final : public inf_ptrace_target
      support.  */
   void follow_fork (inferior *, ptid_t, target_waitkind, bool, bool) override;
 
+  std::string pid_to_str (ptid_t) override;
+
 protected:
 
   void post_startup_inferior (ptid_t ptid) override;
@@ -619,6 +621,64 @@ rs6000_nat_target::xfer_partial (enum target_object object,
     }
 }
 
+/* Search through the list of all kernel threads for the thread
+   that has stopped on a SIGTRAP or SIGINT signal, and return
+   its TID.  Return 0 if none found.  */
+
+static tid_t
+get_signaled_thread_rs6000 (int pid)
+{
+  struct thrdsinfo64 thrinf;
+  tid_t ktid = 0;
+
+  while (1)
+    {
+      if (getthrds (pid, &thrinf,
+                    sizeof (thrinf), &ktid, 1) != 1)
+        break;
+
+      if (thrinf.ti_cursig == SIGTRAP || thrinf.ti_cursig == SIGINT)
+        return thrinf.ti_tid;
+    }
+
+  /* Didn't find any thread stopped on a SIGTRAP signal.  */
+  return 0;
+}
+
+/* If my process is pthreaded I need to return that ptid else ptid_t
+   (pid).  */
+
+static ptid_t
+find_the_return_ptid (pid_t pid)
+{
+  ptid_t ptid = ptid_t (pid);
+  process_stratum_target *proc_target
+        = current_inferior ()->process_target ();
+  inferior *inf = find_inferior_pid (proc_target, pid);
+  thread_info *tp = find_thread_ptid (inf, ptid_t (pid));
+  if (tp == nullptr)
+    for (thread_info *tp1 : inf->threads ())
+       if (tp1->ptid.lwp () == get_signaled_thread_rs6000 (pid))
+         return tp1->ptid;
+  return ptid;
+}
+
+/* Returning "thread" or "process" info as control comes here 
+   during a process switch in multi process debugging.  This 
+   is needed for "info threads" command as a process can be
+   threaded or non threaded in multi process case.  */
+
+std::string
+rs6000_nat_target::pid_to_str (ptid_t ptid)
+{
+  if (ptid.tid () != 0)
+    return string_printf (_("Thread %s"), pulongest (ptid.tid ()));
+
+  else
+    return string_printf (_("Process %s"), pulongest (ptid.pid ()));
+}
+
+
 /* Wait for the child specified by PTID to do something.  Return the
    process ID of the child, or MINUS_ONE_PTID in case of error; store
    the status in *OURSTATUS.  */
@@ -672,7 +732,7 @@ rs6000_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
 	      if (parent_pid > 0)
 		{
 		  ourstatus->set_forked (ptid_t (pid));
-		  return ptid_t (parent_pid);
+		  return find_the_return_ptid (parent_pid);
 		}
 	      aix_remember_child (pid);
 	    }
@@ -687,7 +747,7 @@ rs6000_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
 	      if (child_pid > 0)
 		{
 		  ourstatus->set_forked (ptid_t (child_pid));
-		  return ptid_t (pid);
+		  return find_the_return_ptid (pid);
 		}
 	      aix_remember_parent (pid);
 	    }
@@ -712,7 +772,7 @@ rs6000_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
   else
     *ourstatus = host_status_to_waitstatus (status);
 
-  return ptid_t (pid);
+  return find_the_return_ptid (pid);
 }
 \f
 
-- 
2.31.1


  reply	other threads:[~2022-12-02  7:50 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  6:47 Aditya Kamath1
2022-10-28  9:49 ` Ulrich Weigand
2022-11-08 12:00   ` Aditya Kamath1
2022-11-08 12:17     ` Ulrich Weigand
2022-11-13 18:15       ` Aditya Kamath1
2022-11-15 18:16         ` Ulrich Weigand
2022-11-21  8:27           ` Aditya Kamath1
2022-11-23 14:15             ` Ulrich Weigand
2022-11-23 16:03               ` Aditya Kamath1
2022-11-23 17:09                 ` Ulrich Weigand
2022-11-23 18:45                   ` Aditya Kamath1
2022-11-29  8:18                     ` Aditya Kamath1
2022-11-30 14:57                       ` Ulrich Weigand
2022-12-02  7:50                         ` Aditya Kamath1 [this message]
2022-12-05 18:33                           ` Ulrich Weigand
2022-12-08 10:28                             ` Aditya Kamath1
2022-12-08 10:46                               ` Aditya Kamath1
2022-12-08 16:29                               ` Ulrich Weigand
2022-12-15 12:58                                 ` Aditya Kamath1
2022-12-15 15:53                                   ` Ulrich Weigand
2022-12-19  6:30                                     ` Aditya Kamath1
2022-12-22 12:50                                       ` Ulrich Weigand
2022-12-26 13:18                                         ` Aditya Kamath1
2023-01-09 14:04                                           ` Ulrich Weigand
2023-01-10 12:23                                             ` Aditya Kamath1
2023-01-11 13:31                                               ` Ulrich Weigand
2023-01-13 14:06                                                 ` Aditya Kamath1
2023-01-20 14:44                                                   ` Ulrich Weigand
2023-01-27 14:40                                                     ` Aditya Kamath1
2023-01-30 19:54                                                       ` Tom Tromey
2023-02-02  6:24                                                       ` Aditya Kamath1
2023-02-02  6:35                                                         ` Aditya Kamath1
2023-02-02 17:43                                                           ` Ulrich Weigand
2023-02-03 11:10                                                             ` Aditya Kamath1
2023-02-06 19:07                                                               ` Ulrich Weigand
2023-02-07 11:57                                                                 ` Aditya Kamath1
2023-02-08 18:44                                                                   ` Ulrich Weigand
2023-02-10 16:33                                                                     ` Aditya Kamath1
2023-02-10 16:46                                                                       ` Aditya Kamath1
2023-02-13 19:01                                                                       ` Ulrich Weigand
2023-02-14 14:13                                                                         ` Aditya Kamath1
2023-02-16 19:46                                                                           ` Ulrich Weigand
2023-02-17 11:26                                                                             ` Aditya Kamath1
2023-02-17 12:04                                                                               ` Ulrich Weigand
2023-02-17 13:22                                                                                 ` Aditya Kamath1
2023-02-17 14:18                                                                                   ` Ulrich Weigand
2023-02-17 15:15                                                                                     ` Aditya Kamath1
2023-02-17 19:14                                                                                       ` Ulrich Weigand
2022-11-08 12:00 Aditya Kamath1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CH2PR15MB354486F155F5CC97501D056DD6179@CH2PR15MB3544.namprd15.prod.outlook.com \
    --to=aditya.kamath1@ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.com \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).