Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch

[Aditya Kamath1 via Gdb-patches <gdb-patches@sourceware.org>]

Hi all,

This applies in a multithread case.

Why we need inferior_ptid reset in wait?? AIX uses pthread debug library which has to be intialised first. On an event of wait due to a thread creation, once we fetch the pid using waitpid(), the following condition satisfies..


/* Check whether libpthdebug might be ready to be initialized.*/

  if (!pd_active && status->kind () == TARGET_WAITKIND_STOPPED

  && status->sig () == GDB_SIGNAL_TRAP)

 and we enter pd_activate() to. On a successful pthread debug library initialisation we have to initiate a thread debug session using pthdb_session_init(). While we do that, we have call backs to read symbol, data etc. The problem is here where we are not able to read them successfully due to incorrect process ID information. It is not able to fetch the right address to read in pdc_read_data() where we read target_read_memory() and pdc_symbol_addrs().

Kindly read https://www.ibm.com/docs/en/aix/7.1?topic=programming-developing-multithreaded-program-debuggers for more on what I shared.
Developing multithreaded program debuggers<https://www.ibm.com/docs/en/aix/7.1?topic=programming-developing-multithreaded-program-debuggers>
The pthread debug library (libpthdebug.a) provides a set of functions that allows developers to provide debug capabilities for applications that use the pthread library.
www.ibm.com<http://www.ibm.com>

What we are thinking might be the solution??

Since we initialise the gdb with an observer to notify when there is a thread ptid change, on a wait event the inferior_ptid is set to null by switch_to_no_thread () with reinit_cache_frame (). Essentially with this we loose all our pid information needed to read our data and symbols as now our thread PTID is changed to null. So it is essential for us with the way AIX code is designed that we either reset our inferior_ptid in AIX thread wait code before we go out to the non-target dependent code like target.c, infrun.c to do it for us, or use

      thread_change_ptid (process_stratum_target *targ,

  ptid_t old_ptid, ptid_t new_ptid)


to inform GDB so that we can reset and get the right address for target_read_memory() in aix-thread.c file.


It will be great if you could tell us if we are thinking right at this moment.
________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 19 July 2022 17:51
To: 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>; simark@simark.ca <simark@simark.ca>
Subject: Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch

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

>The reason:- Since a new thread addition causes a thread target to
>wait, in AIX once the event ptid is got with the waitpid(), we need to
>set the inferior_ptid variable. Every time we come into
>aix_thread_target::wait() we check if libpthdebug might be ready to be
>initialized.In doing so we call pd_activate(). Here the session needs
>to be successfully initialised failing to which just a pid is >returned.
>We do not enter pd_update() in the former case to take care of the rest
>of the thread addition process. The pthdb_session_init() is dependent
>on inferior_ptid variable as per our observations to return
>PTHDB_SUCCESS.

I think the change to pd_enable makes sense, passing 1 to pd_activate
seems clearly incorrect now.  Simon, you recently changed pd_activate
to take a PID instead of a boolean - any comments on this?

However, I do not see why the change to ::wait is necessary, or even
correct.  Note that when ::wait calls pd_activate or pd_update, it
already passes the correct pid.  I do not see any path from ::wait
to pd_enable.

Bye,
Ulrich