Hi Ulrich,

>If not, are shared libraries actually detected correctly in the
>second inferior (e.g. does "info sharedlibrary" show them correctly
>in the second inferior)?  If not, maybe solib-aix.c also needs to
>be reviewed whether it handles multiple inferiors correctly

You were right about this in the previous email. There are 4 shared libraries all present in their respective archived files, we try to access when a new inferior is created. They are:-

/usr/lib/libpthreads.a(shr_comm.o)

/usr/lib/libcrypt.a(shr.o)

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

/usr/lib/libc.a(shr.o)

Consider the patch for the analysis as shown below:-


--- solib-aix.c_orig    2022-12-23 12:05:39 +0000

+++ solib-aix.c 2022-12-26 06:12:06 +0000

@@ -615,6 +615,7 @@

     (gdb_bfd_openr_next_archived_file (archive_bfd.get (), NULL));

   while (object_bfd != NULL)

     {

+      printf ("object_bfd is %s --- compared with --- member_name is %s in path %s \n", bfd_get_filename (object_bfd.get ()), member_name.c_str (), pathname);

       if (member_name == bfd_get_filename (object_bfd.get ()))

        break;

Here I have added a print statement to ensure we are able to find the member in the archive.

What's interesting is for the first inferior this works fine for all shared libraries. For the second one and every inferior thereafter the output is as shown below in the next paragraph,


object_bfd is shr.o --- compared with --- member_name is shr_comm.o in path /usr/lib/libpthreads.a(shr_comm.o)

object_bfd is /usr/lib/libpthreads.a(shr_comm.o) --- compared with --- member_name is shr_comm.o in path /usr/lib/libpthreads.a(shr_comm.o)

I was surprised that the bfd_get_filename (object_bfd.get ()) is returning the pathname instead of the object file descriptor. Everything until here seems to correct in the solib_aix_bfd_open () function and this makes it hard for me to understand what is going on. Even if I allow a pathname match to the member_name we end up losing all the information of our threads in the first process though we still have the process information.

One more thing I want to share is that the inferior is getting correctly aligned wherever current_inferior () is used to get the inferior's shared library list or information.

So right now, I do not have answers to why the pathname is getting returned and if I need to correct the same how I can. As a consequence, the Shared libraries are missing for new inferior.  Kindly guide me on how this can be solved.

The rest of the patch I am attempting to solve this remains unchanged.

Have a nice day ahead.

Thanks and regards,
Aditya.


________________________________
From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Sent: 22 December 2022 18:20
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:

>So, I guess if we manage to do something similar just like for the
>first inferior, we will get to the solution, but I did not understand
>how Linux might be reading the symbol again and again for a new
>inferior or AIX for that matter for the first inferior.  Kindly let
>me know how we can do something similar or are we missing something
>here that I have not kept in mind in our attempt to solve this for
>AIX and GDB community.

So the way is works on Linux is that linux-thread-db.c registers
both an inferior_created observer and a new_objfile observer.

The inferior_created observer gets called immediately after the
new inferior is noticed - at this point, only the main executable
is detected by GDB, not any of the shared libraries.  So this will
only successfully detect a libpthread-linked executable if it was
*statically* linked.  For dynamically linked executables, the
new_objfile observer will later get called as well, once for each
shared library.  As soon as this happens for the libpthread shared
library, the fact that the inferior is multithreaded is detected.

At first glance, this should actually work the same on AIX - the
aix-thread.c file also registers both inferior_created and
new_objfile observers.  Not sure why this doesn't work ...
Do you see the new_objfile observer being called for all the
shared libraries in the second inferior?

If not, are shared libraries actually detected correctly in the
second inferior (e.g. does "info sharedlibrary" show them correctly
in the second inferior)?  If not, maybe solib-aix.c also needs to
be reviewed whether it handles multiple inferiors correctly ...

Bye,
Ulrich