Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>,
	Aditya Kamath1 <Aditya.Kamath1@ibm.com>,
	"simon.marchi@efficios.com" <simon.marchi@efficios.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch
Date: Mon, 25 Jul 2022 11:30:36 -0400	[thread overview]
Message-ID: <841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca> (raw)
In-Reply-To: <ef0a6afec790999042c60371917266d8e9b44841.camel@de.ibm.com>



On 2022-07-25 08:21, Ulrich Weigand wrote:
> 
> Aditya Kamath1 <Aditya.Kamath1@ibm.com> wrote:
> 
>> The cause of the bug :- Since, for the GDB core we are
>> switch_to_no_thread() i.e. we do not have a thread till we return the
>> pid from the wait() there is no thread. So, when a call is made from
>> pd_activate() in wait() of aix-thread.c, to pthdb_session_init() we are
>> going to recieve PTHDB_NOT_THREADED.
> 
> Thanks for the explanation.  I wasn't aware the use of
> inferior_ptid happens in some of callback routines used
> by the pthdb_session_init() library routine.

Thanks, me neither, but it makes sense.

> I still think the proposed fix isn't really ideal.  Can you instead
> try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid
> in pd_activate() before calling pthdb_session_init(), with a comment
> explaining that this is needed for the callbacks?

That sounds like a good idea, this way, from the point of view of the
caller of pd_activate, pd_activate does not care about global state.
That's how we can do baby steps towards relying less on global state
implicitly.  The next step could be to try to make each individual
callback switch to the right global context, based on what they need.

You just need to be careful, some parts of GDB expect inferior_ptid, the
current thread, the current inferior and the current program space to be
sync'ed.  If you just set inferior_ptid,  you need to make sure to only
call functions that use inferior_ptid, not the other current stuff.
There is not practical way to know this, you have to carefully inspect
what is called.  To avoid this kind of problems, you can temporarily
switch thread (using scoped_restore_current_thread + switch_to_thread),
which will set all the current stuff mentioned above.  But sometimes
this isn't possible, especially in thw wait method, because there isn't
always a thread_info for the ptid you are handling yet, so you can't
switch to it.

Given the AIX target only supports one inferior for now, the current
inferior and program space should be correct.  But to support
multi-inferior, it will be important to keep that in mind.  You might
have to switch to the right inferior in addition to setting
inferior_ptid in pd_acticate.

This hunk in the patch:

diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c
index 4c9195a7f12..91466a17647 100644
--- a/gdb/aix-thread.c
+++ b/gdb/aix-thread.c
@@ -976,7 +976,7 @@ pd_enable (void)
   /* If we're debugging a core file or an attached inferior, the
      pthread library may already have been initialized, so try to
      activate thread debugging.  */
-  pd_activate (1);
+  pd_activate (inferior_ptid.pid());
 }

looks right to me (except the missing space before the parenthesis).  It
looks like an oversight in my "gdb: fix
{rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid"
patch, I forgot to update that call to pd_activate.  Note that the old
parameter to pd_activate was SET_INFPID, and if set, pd_update would
change the current thread to reflect the thread ptid, if thread
debugging was enabled.  The current code no longer does that.  If that
was important, we can re-introduce it here: make pd_enable switch to the
thread with the ptid returned by pd_activate.

Simon

  reply	other threads:[~2022-07-25 15:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 15:51 Aditya Kamath1 via Gdb-patches
2022-07-16  3:57 ` Aditya Kamath1 via Gdb-patches
2022-07-19 12:21   ` Ulrich Weigand via Gdb-patches
2022-07-22 17:03     ` Aditya Kamath1 via Gdb-patches
2022-07-25 12:04       ` Aditya Kamath1 via Gdb-patches
2022-07-25 12:21         ` Ulrich Weigand via Gdb-patches
2022-07-25 15:30           ` Simon Marchi via Gdb-patches [this message]
2022-07-29  9:23             ` Aditya Kamath1 via Gdb-patches
2022-08-01 17:25               ` Aditya Kamath1 via Gdb-patches
2022-08-03 16:22               ` Ulrich Weigand via Gdb-patches
2022-08-04 15:15                 ` Aditya Kamath1 via Gdb-patches
2022-08-05  5:01                   ` Aditya Kamath1 via Gdb-patches
2022-08-05 11:53                     ` Ulrich Weigand via Gdb-patches
2022-08-05 14:11                       ` Aditya Kamath1 via Gdb-patches
2022-08-05 14:18                         ` Ulrich Weigand via Gdb-patches
2022-08-05 14:24                           ` Aditya Kamath1 via Gdb-patches
2022-08-09  2:36                             ` Aditya Kamath1 via Gdb-patches
2022-08-09 13:41                               ` Ulrich Weigand via Gdb-patches
2022-08-10  6:57                                 ` Aditya Kamath1 via Gdb-patches

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=841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca \
    --to=gdb-patches@sourceware.org \
    --cc=Aditya.Kamath1@ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=sangamesh.swamy@in.ibm.com \
    --cc=simark@simark.ca \
    --cc=simon.marchi@efficios.com \
    /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