public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Aditya Vidyadhar Kamath <ADITYA.VIDYADHAR.KAMATH@ibm.com>,
	Joel Brobecker via Gdb-patches <gdb-patches@sourceware.org>
Cc: Sangamesh Mallayya <sangamesh.swamy@in.ibm.com>
Subject: Re: [PATCH] Use current_inferior ()->pid for AIX
Date: Tue, 5 Apr 2022 08:47:08 -0400	[thread overview]
Message-ID: <87169b93-8be2-5ccd-6b58-51b395a367bd@polymtl.ca> (raw)
In-Reply-To: <BN8PR15MB2867CB839CCB30C0569470D4B51F9@BN8PR15MB2867.namprd15.prod.outlook.com>

Hi Aditya,

I don't think that using current_inferior throughout is a good solution
to your problems.  It will be case by case, unfortunately there's no
easy way out of this but to dig in GDB and understand its internals a
bit.

> From eb10e0ebc422d01f5ce96786f0bcf78a4f57d7ef Mon Sep 17 00:00:00 2001
> From: Aditya Vidyadhar Kamath
>  <adityakamath@li-ee942a4f-4ab2-47e9-8494-fb53eafbb9e1.ibm.com>
> Date: Wed, 30 Mar 2022 11:19:14 +0530
> Subject: [PATCH] Use current_inferior ()->pid for AIX.
> 
> ---
>  gdb/aix-thread.c     | 15 ++++++++-------
>  gdb/rs6000-aix-nat.c |  8 ++++----
>  2 files changed, 12 insertions(+), 11 deletions(-)
> 
> diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c
> index 85be4c15f1c..9331de3beb2 100644
> --- a/gdb/aix-thread.c
> +++ b/gdb/aix-thread.c
> @@ -708,7 +708,7 @@ get_signaled_thread (void)
>  
>    while (1)
>      {
> -      if (getthrds (inferior_ptid.pid (), &thrinf,
> +      if (getthrds (current_inferior ()->pid, &thrinf,
>  		    sizeof (thrinf), &ktid, 1) != 1)

This function doesn't seem to depend on the current inferior/thread, so
it could easily be changed to receive the pid as a parameter.

>  	break;
>  
> @@ -791,7 +791,7 @@ sync_threadlists (void)
>  
>    /* Apply differences between the two arrays to GDB's thread list.  */
>  
> -  infpid = inferior_ptid.pid ();
> +  infpid = current_inferior ()->pid;
>    for (pi = gi = 0; pi < pcount || gi < gcount;)
>      {
>        if (pi == pcount)
> @@ -883,11 +883,11 @@ pd_update (int set_infpid)
>    struct thread_info *thread = NULL;
>  
>    if (!pd_active)
> -    return inferior_ptid;
> +    return ptid_t (current_inferior ()->pid);
>  
>    status = pthdb_session_update (pd_session);
>    if (status != PTHDB_SUCCESS)
> -    return inferior_ptid;
> +    return ptid_t (current_inferior ()->pid);

Here, the pd_update function seems to want to return the event ptid
unmodified.  So, perhaps that ptid could be passed by the caller and
returned here.  Or, pd_update could be changed to return an
optional<ptid_t> and the caller deals with returning the right ptid.

>  
>    sync_threadlists ();
>  
> @@ -897,7 +897,7 @@ pd_update (int set_infpid)
>    if (tid != 0)
>      thread = iterate_over_threads (iter_tid, &tid);
>    if (!thread)
> -    ptid = inferior_ptid;
> +    ptid = ptid_t (current_inferior ()->pid);
>    else
>      {
>        ptid = thread->ptid;
> @@ -921,7 +921,7 @@ pd_activate (int set_infpid)
>  			       &pd_session);
>    if (status != PTHDB_SUCCESS)
>      {
> -      return inferior_ptid;
> +      return ptid_t (current_inferior ()->pid);

This is the same idea as in pd_update.

>      }
>    pd_active = 1;
>    return pd_update (set_infpid);
> @@ -932,11 +932,12 @@ pd_activate (int set_infpid)
>  static void
>  pd_deactivate (void)
>  {
> +  ptid_t ptdrtn = ptid_t (current_inferior ()->pid)	
>    if (!pd_active)
>      return;
>    pthdb_session_destroy (pd_session);
>    
> -  pid_to_prc (&inferior_ptid);
> +  pid_to_prc (&ptdrtn);

Since pid_to_prc only writes to ptdrtn, it essentially a no-op.  I would
try just removing that call.  It was used to modify inferior_ptid after
the thread layer was disabled, which does not seem useful to me.

> diff --git a/gdb/rs6000-aix-nat.c b/gdb/rs6000-aix-nat.c
> index 8563aea313a..0b8e4d2c687 100644
> --- a/gdb/rs6000-aix-nat.c
> +++ b/gdb/rs6000-aix-nat.c
> @@ -397,7 +397,7 @@ rs6000_nat_target::xfer_partial (enum target_object object,
>  				 ULONGEST offset, ULONGEST len,
>  				 ULONGEST *xfered_len)
>  {
> -  pid_t pid = inferior_ptid.pid ();
> +  pid_t pid = current_inferior ()->pid;
>    int arch64 = ARCH64 ();
>  
>    switch (object)

Here, inferior_ptid should be valid, this change should not be
necessary.

> @@ -525,11 +525,11 @@ rs6000_nat_target::wait (ptid_t ptid, struct target_waitstatus *ourstatus,
>  
>  	  /* Claim it exited with unknown signal.  */
>  	  ourstatus->set_signalled (GDB_SIGNAL_UNKNOWN);
> -	  return inferior_ptid;
> +	  return ptid_t (current_inferior ()->pid);
>  	}
>  
>        /* Ignore terminated detached child processes.  */
> -      if (!WIFSTOPPED (status) && pid != inferior_ptid.pid ())
> +      if (!WIFSTOPPED (status) && pid != pid_t(current_inferior ()->pid))
>  	pid = -1;
>      }
>    while (pid == -1);

The target_ops::wait method implemenattions should ne rely on the
current inferior either.  I don't think that this target supports
debugging multiple processes at the same time, but imagine that it does,
eventually.  When rs6000_nat_target::wait gets called, the current
inferior is one of the inferiors managed by that target, at random.  So
what the wait method needs to do is fetch an event from the OS, and
returning, regardless of which inferior it applies to (except if a ptid
argument is given).  So, you should never need to use either
inferior_ptid nor current_inferior in wait.

> @@ -658,7 +658,7 @@ rs6000_nat_target::xfer_shared_libraries
>    if (writebuf)
>      return TARGET_XFER_E_IO;
>  
> -  gdb::byte_vector ldi_buf = rs6000_ptrace_ldinfo (inferior_ptid);
> +  gdb::byte_vector ldi_buf = rs6000_ptrace_ldinfo (ptid_t(current_inferior ()->pid));
>    result = rs6000_aix_ld_info_to_xml (target_gdbarch (), ldi_buf.data (),
>  				      readbuf, offset, len, 1);

This is used by xfer_partial, where inferior_ptid should be valid, so
this change shouldn't be necessary.

Simon

  parent reply	other threads:[~2022-04-05 12:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29  6:58 Aditya Vidyadhar Kamath
2022-03-29 13:01 ` Simon Marchi
2022-03-30 13:04   ` Aditya Vidyadhar Kamath
2022-04-05 12:15     ` Aditya Vidyadhar Kamath
2022-04-05 12:47     ` Simon Marchi [this message]
2022-04-12 13:32       ` Aditya Vidyadhar Kamath
2022-04-18  6:33         ` Aditya Vidyadhar Kamath
2022-04-21 11:41         ` Aditya Vidyadhar Kamath
2022-04-21 14:51         ` Simon Marchi
     [not found]           ` <BN8PR15MB2867D6D625DD0B353C99D3A3B5DD9@BN8PR15MB2867.namprd15.prod.outlook.com>
2022-05-30 12:45             ` Simon Marchi
2022-06-10 14:47               ` Aditya Vidyadhar Kamath
2022-06-15  4:03                 ` Aditya Vidyadhar Kamath
2022-06-23 20:40                   ` Aditya Vidyadhar Kamath
2022-06-27 12:55                 ` Fw: " Aditya Vidyadhar Kamath
2022-06-27 15:11                   ` Simon Marchi
2022-07-04 19:28                   ` Simon Marchi
2022-07-06  4:25                     ` Fw: RE: [PATCH] Fix assert pid != 0 assertion failure in AIX Aditya Vidyadhar Kamath
2022-07-06 17:50                       ` Simon Marchi
2022-07-07  8:27                         ` Aditya Vidyadhar Kamath
2022-07-07 13:56                           ` Simon Marchi
     [not found] <BN6PR15MB13130BF943A019871F8F4E0EB5119@BN6PR15MB1313.namprd15.prod.outlook.com>
2022-05-02 14:50 ` [PATCH] Use current_inferior ()->pid for AIX Ulrich Weigand

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=87169b93-8be2-5ccd-6b58-51b395a367bd@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=ADITYA.VIDYADHAR.KAMATH@ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sangamesh.swamy@in.ibm.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).