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: Tue, 29 Nov 2022 08:18:38 +0000	[thread overview]
Message-ID: <CH2PR15MB354465C64C4B32DA395C110AD6129@CH2PR15MB3544.namprd15.prod.outlook.com> (raw)
In-Reply-To: <CH2PR15MB3544AB7CA50F834387522DB0D60C9@CH2PR15MB3544.namprd15.prod.outlook.com>


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

Hi all,

Please find attached the new patch. [Kindly see: 0001-Fix-multi-thread-bug-fix-in-AIX.patch].

This patch works for a single process with multiple threads and multiple process with detach on fork on. Kindly find the program1 and 2 below and the outputs named as output 1 and output 2 respectively.

The issue:-

When we ran the unit test cases, we realised we have a problem in the multi process detach on fork on case where this patch fails. The issue is when there is interrupt pressed while a thread is running [threads after using fork() and stuck in while (1);], it somehow manages to switch the process as shown highlighted in bold in output 3 below this email. Due to this what should have been shown as threads is now being shown as process.

A detailed explaination on the solution proposed for single process:-

In AIX we were adding a main thread named say 'Thread 1' extra when we already had a main process thread named say 'process 100'. This created a mess while sinking and with the recent change in the get_aix_thread_info () function where it won't allow any thread with no private data there by leading to a crash.

So, the proposed patch[attached in this email] modifies our sync_threadlists ()  function where a check if a process has tid or not. If it has then we know my program is multi-threaded and I need to change main process thread ptid from 'process 100' to 'Thread 1' as Ulrich mentioned in the previous threads like ptid (pid, 0, 0) to ptid (pid, 0, tid or pthreadID). This is done by thread_change_ptid () in the patch.

While this is done, there are cases where when we read target memory we need to be in the right context.. Hence, the proposed patch changes inferior_ptid in pdc_read_data() as mentioned by Ulrich.
+      inferior_ptid = ptid_t (user_current_pid);

Here's the thing we were not counting our main thread in GDB thread lists [gcount].. Now we do so. The proposed patch has removed the condition.
-  if (PD_TID (thread->ptid))

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)

These changes solve the single process case.

A detailed explaination on the solution proposed for multi process with multi thread case:-

Consider my main program is multi-threaded and each thread can fork().. After we record all events there are two things, we need to take care of in my rs6000-aix-nat.c..

1:- There can be a child event whose parent can be pthreaded or multi-threaded. The negation of this is fine since we anyway can return only ptid_t (pid).

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.

Having said that the propsed patch uses lwp parameter inorder to store the kernel thread ID so that we can fetch it here and use it here.

2:- There are cases where we need to pass my ptid_t (pid, lwp, tid) to aix-thread.c instead of ptid_t (pid)..


If we try to fix 1 this way, then then below assertion causes us trouble if we go through aix-thread.c for our beneath->wait. Hence the proposed patch has it removed.

-  /* The target beneath does not deal with threads, so it should only return
-     pid-only ptids.  */
-  gdb_assert (ptid.is_pid ());


We are not able to know why our output 3 is switching to a process[ Output 3 in the mail below]..

So, we are at one of the threads of process 1. On an interrupt we need to switch our threads to the thread that caused it. But the GDB core is saying we switched our process. It shouldn't as we are in the same process. And I also checked if we returned the correct ptid that raised the interrupt and we do.

I tried to debug on what is going on in the GDB core but failed to understand for the last couple of days, and therefore I did not succeed.

If I do not understand, then I will not be able to solve this problem for AIX and GDB. Hence, I wish to reach out to you all after this effort for a solution.

Since you all are experts having vast experience and knowledge in GDB, kindly let me know what is going on in the output 3 case [pasted below in this email] or the things mentioned in the patch are done using a wrong method. If so, then let me know what we can do correctly and efficiently from here.

Hope to seek a reply. Have a nice day ahead.

Thanks and regards,
Aditya



----------------------------------------------------------------
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 8323570)]

I am parent

[New inferior 3 (process 17957172)]

I am parent

^C

Thread 1.1 received signal SIGINT, Interrupt.

[Switching to process 16777620]

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 ?? ()


________________________________
From: Gdb-patches <gdb-patches-bounces+aditya.kamath1=ibm.com@sourceware.org> on behalf of Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org>
Sent: 24 November 2022 00:15
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: [EXTERNAL] Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch

Hi Ulrich,

>static int
>giter_count (struct thread_info *thread, void *countp)
>{
>  if (PD_TID (thread->ptid))
>    (*(int *) countp)++;
>  return 0;
>}
>Maybe that comment is wrong about pthreaddebug not including
>the main thread?   Or maybe that changed between AIX versions?

>In any case, something needs to be fixed here.

Even if we fix it here [assuming we are succesful], in the delete_thread_1 () in thread.c we will fail to hit thread->deletable as true while we attempt delete_thread (gbuf [gi]).. Because refcount will not be 0 when we attempt to delete main thread with ptid (pid, 0, 0). {see func below}


bool

thread_info::deletable () const

{

  /* If this is the current thread, or there's code out there that

     relies on it existing (refcount > 0) we can't delete yet.  */



  return refcount () == 0 && !is_current_thread (this);

}


I will be trying to replace the main thread instead like  thread_change_ptid (proc_target, gptid, pptid) subject to a condition check that gptid.tid () == 0.. Otherwise, if it is not a main thread [gptid.tid () != 0], we can delete gbuf[gi].. We can apply this else where as well in sync_threadlists ().

Let me know if we have an alternate optimal option that can delete this thread or why the solution in the above paragraph can fail..

Rest of the things I will handle. No problem.

Thanks and regards,
Aditya..


________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 23 November 2022 22:39
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:
>Hmm. So, something is going wrong here..
>gcount = 0;
>  iterate_over_threads (giter_count, &gcount);
>  g = gbuf = XNEWVEC (struct thread_info *, gcount);
>  iterate_over_threads (giter_accum, &g);
>  qsort (gbuf, gcount, sizeof *gbuf, gcmp);

Looks like this is deliberate:

/* 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)++;
  return 0;
}

Maybe that comment is wrong about pthreaddebug not including
the main thread?   Or maybe that changed between AIX versions?

In any case, something needs to be fixed here.

Bye,
Ulrich


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

From 5521677adbd492472de047a9d31597addb9502f4 Mon Sep 17 00:00:00 2001
From: Aditya Vidyadhar Kamath <Aditya.Kamath1@ibm.com>
Date: Tue, 29 Nov 2022 00:20:19 -0600
Subject: [PATCH] Fix multi thread bug in AIX

---
 gdb/aix-thread.c     | 66 +++++++++++++++++++++-----------------------
 gdb/rs6000-aix-nat.c | 48 ++++++++++++++++++++++++++++++--
 2 files changed, 77 insertions(+), 37 deletions(-)

diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c
index e556c153576..6783aa4999f 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,8 +691,8 @@ 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.
-   Return 0 if none found.  */
+   that has stopped on a SIGTRAP or SIGINT signal, and return
+   its TID.  Return 0 if none found.  */
 
 static pthdb_tid_t
 get_signaled_thread (int pid)
@@ -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,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);
+		  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 +1093,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..db45a95952a 100644
--- a/gdb/rs6000-aix-nat.c
+++ b/gdb/rs6000-aix-nat.c
@@ -619,6 +619,48 @@ 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;
+}
+
 /* 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 +714,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 +729,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 +754,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-11-29  8:18 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 [this message]
2022-11-30 14:57                       ` Ulrich Weigand
2022-12-02  7:50                         ` Aditya Kamath1
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=CH2PR15MB354465C64C4B32DA395C110AD6129@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).