Re: RFC: ppc-aix shared object support in GDB

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> This is a question I am asking myself as part of my project of
Joel> cleaning up the ppc-aix solib & core file support in GDB.

I'm not really an expert in the so-list code but I thought I would throw
an idea out there.

I'm not really sure it is a better idea, see below.

Joel>   1. Being able to open the actual shared-object bfd instead
Joel>      of the archive's bfd;
Joel>   2. Have "info sharedlibrary" also display which shared object
Joel>      has been loaded instead of just the archive name.

My first thought was that this is a kind of abstraction violation.
That is, IIUC, the AIX code creates the so_list objects in the first place.
So why would it need special machinery?  It could just subclass so_list
and put the extra information there.

In this approach, we'd still need a big change to the bfd_open method,
but just to change it to:

    bfd *(*bfd_open) (struct so_list *item);

Subsequent grepping shows a bit of a precedent:

    struct darwin_so_list
    {
      /* Common field.  */
      struct so_list sl;
      /* Darwin specific data.  */
      struct lm_info li;
    };

Then for problem #2, add a target_so_ops method to print the solist
name.


There are two reasons I'm not certain this is better.

First, I'm not super familiar with all the code in question, so some
assumption I'm making may be wrong.  Like, maybe solists are also made
generically and so the bfd_open change can't be done.  The Darwin code
seems to imply that it is ok, but still...

Second, the printing part seems tricky, in that perhaps you'd want
better output for MI, with the archive member name as a separate field.
This may be a pain.

Joel> At first glance, does it sound like a reasonable plan? I think
Joel> that definitely beats what's currently being done, which is
Joel> a certain amount of ad hoc code which takes care of opening
Joel> the bfds, creating the objfiles, doing the relocation, etc.
Joel> But perhaps there is something I haven't seen that we could use
Joel> already?

FWIW, I think your plan is reasonable.
It is definitely better than what we have today.
So please consider the above food for thought, not any sort of request
blocking whatever route you want to take.

thanks,
Tom