gdb: multiple solib_ops per program space

This patch adds the possibility for a program space to have multiple
solib_ops.  The motivation for this is to support ROCm (GPU) debugging
more cleanly.

Currently, when debugging a ROCm program, in order to be able to list
device code objects (the equivalent of shared libraries but for the
GPU), we install an instance of rocm_solib_ops as the program space's
sole solib_ops.  But in order to still be able to list host shared
libraries, the rocm_solib_ops wraps the previously installed solib_ops
(currently always an svr4_solib_ops instance) and forwards method calls
to it.

By allowing program spaces to use multiple solib_ops, each solib_ops can
work side by side and rocm_solib_ops won't need to care about the host
solib_ops.

This change starts by making program_space::m_solib_ops a vector of
solib_ops_up instead of a single solib_ops_up, and it propagates from
there.

program_space::set_solib_ops becomes program_space::add_solib_ops.  I
put in the restriction that there can be only one instance of a given
kind of solib_ops in the vector (it wouldn't make sense to have two
svr4_solib_ops instances in there, it would likely be a bug).

Remove program_space::unset_solib_ops, but add
program_space::remove_solib_ops (to remove a single solib_ops) and
program_space::clear_solib_ops (to remove all solib_ops).  Removing an
solib_ops now automatically removes all the solibs produced by that
solib_ops, to avoid having solibs with stale solib_ops backlinks.

Add program_space::find_solib_ops, which can be used to find the
instance of a given kind of solib_ops.

Then, the code in solib.c gets adapted to deal with the fact that there
might be multiple solib_ops.  The logic is done on a case by case basis:

 - update_solib_list: where we call open_symbol_file_object, iterate
   over all solib_ops until we find one that knows how to find and open
   the main executable

 - also update_solib_list: where we fetch the list of current SOs from
   the inferior and compare it against the list of SOs know to GDB,
   iterate over all solib_ops and fetch current SOs from all of them.
   When comparing the SOs fetched from the solib_ops with the SOs
   known to GDB, also compare the solib_ops before considering it a
   match.

 - print_solib_list_table: to determine whether to print the namespace
   column, iterate over all solib_ops until we find one for which
   supports_namespaces returns true and num_active_namespaces returns
   greater than 0.  If the namespace column is printed and some solibs
   are from an solib_ops that doesn't support namespaces, skip the
   column.

 - info_linker_namespace_command: iterate over all solib_ops.  For each
   solib_ops, print all namespaces.

 - solib_keep_data_in_core: iterate over all solib_ops until one says
   that the given memory range should be kept.

 - clear_solib: call clear_solib on all solib_ops

 - solib_create_inferior_hook: call create_inferior_hook on all
   solib_ops

 - in_solib_dynsym_resolve_code: iterate over all solib_ops until one
   says that the given PC falls into dynsym resolve code

 - update_solib_breakpoints: call update_breakpoints on all solib_ops

 - handle_solib_event: call handle_event on all solib_ops.  The event
   normally concern only one of those solib_ops, but at the moment we
   have no way to tell which solib_ops that is.  Perhaps, in the future,
   we can link bp_shlib_event breakpoints to which solib_ops the event
   is for, and call handle_event just for that solib_ops.  In the mean
   time, it is expected that for solib_ops not concerned by the event,
   calling handle_event will have no effect.

 - reload_shared_libraries: call clear_solib on all solib_ops

 - solib_linker_namespace_count: sum the number of active linker
   namespace over all solib_ops.  I don't know if this makes sense, but
   there is no known case today of two solib_ops supporting namespaces
   working side-by-side, so it's a theoretical problem for now.

With multiple solib_ops, the concept of
iterate_over_objfiles_in_search_order becomes a bit more complex.  The
implementation is mostly based on suppositions on my part.  The idea
implemented in this patch is to give priority to the solib_ops
responsible for an objfile when searching for a symbol.  If you're
stopped debugging some GPU code and look up a variable, and there is a
variable by that name both on the host and GPU side, I believe it is
more likely that you are interested in the GPU one.

Since we're going to ask multiple solib_ops to search successively,
change solib_ops::iterate_over_objfiles_in_search_order to return a
bool, to indicate if the search was successful or if we should continue.

Then, change solib_ops::iterate_over_objfiles_in_search_order (the
implementation used by all except svr4_solib_ops) to only search the
objfiles from that solib_ops as well as (optionally) the main objfile
(program_space::symfile_object_file).  The idea regarding the main
objfile is that it falls under the "linking domain" of the host-side
solib_ops, even though it wasn't produced by that solib_ops.
svr4_solib_ops has its own implementation of
iterate_over_objfiles_in_search_order, which does check the main
objfile.

Checking the main objfile is predicated by the HANDE_MAIN_OBJFILE
solib_ops constructor parameter, for which rocm_solib_ops passes false.

Then in program_space::iterate_over_objfiles_in_search_order, the search
strategy becomes:

  - if there is a current objfile:
    - if that objfile was contributed by an solib_ops:
      - call that solib_ops' iterate_over_objfiles_in_search_order
    - else:
      - search the current objfile by itself

If we didn't find anything interesting, we continue the search by asking
other solib_ops to search:

  - for all solib_ops except the one searched before (if any):
    - call that solib_ops' iterate_over_objfiles_in_search_order

Finally, "orphan" objfiles (not mapped to any solib) haven't been
searched (except possibly the current objfile), so:

  - for all objfile without an solib_ops backlink, except the current one (if any):
    - search that objfile

Note that if the current objfile is the main one
(program_space::symfile_object_file), then we won't enter the host
solib_ops::iterate_over_objfiles_in_search_order in the first part,
because that objfile is not associated to any solib, and therefore to
any solib_ops.  Instead, we will enter it in the first iteration of the
second part.  This relies on the fact that the host solib_ops will
always be first in the solib_ops list, with complementary solib_ops
following.  This is always true today, given the order in which
solib_ops instances are pushed.  Otherwise, we could go look for the
solib_ops for which M_HANDLE_MAIN_OBJFILE is true, but it didn't seem
like it was worth the extra complexity.

I wrote the gdb.rocm/symbol-lookup.exp test to try to exercise this
symbol lookup order thing.  The test program loads some shared libraries
and some ROCm code objects, then does some symbol lookups while stopped
in different places.

Finally, the goal of all this, rocm_solib_ops gets changed to not wrap a
host solib_ops anymore!  rocm_solib_ops previously had to use
lm_info_svr4, to avoid confusing svr4_solib_ops.  It doesn't have to
anymore, so introduce a simpler lm_info_rocm that just holds an address.

rocm_solib_ops no longer needs to implement a bunch of methods just to
forward the call to the host solib_ops, so remove them.  In the methods
that rocm_solib_ops actually needs to implement, it no longer needs to
call the host ops, which simplifies things.

Things also get simpler at the points where we push a new
rocm_solib_ops.

Change-Id: I260cdc0dcb9b11f33040059f300719dacac63d69
Approved-By: Tom Tromey <tom@tromey.com>