[RFA 0/14] Remove quadratic behaviour from probes linker interface

[Gary Benson <gbenson at redhat dot com>]

Hi all,

This patch removes a piece of quadratic behaviour introduced with the
probes-based runtime linker interface, partially fixing PR 15590 [1].

The problem is that target_so_ops->current_sos is expected to return
a freshly allocated list of libraries to update_solib_list, its only
caller.  For each solib returned, update_solib_list either adds them
to its own internal list or frees them if they are already present.
This makes sense for the standard interface, which reads everything
from the inferior into a list and returns it, but the probes interface
already has a list built by the time target_so_ops->current_sos is
called.  It needs to copy this list to return, which is quadratic and
generally wasteful.

This series alters solib-svr4's target_so_ops->current_sos to retain a
pointer to each copy solib it passes to update_solib_list.  The copies
are "acquired" before being passed to update_solib_list, and copies
that update_solib_list frees are not freed but released back to
solib-svr4's target_so_ops->current_sos for reuse.  Copies that are
not released become the responsibility of update_solib_list (and GDB
as a whole) and solib-svr4's target_so_ops->current_sos discards its
pointers to them, creating a fresh copy the next time around.  This
means solibs read by the probes-based interface are copied at most
twice.

Patch 1 of this series alters free_so to not free the containing
so_list object: this now becomes the responsibility of the individual
targets.  Patches 2-13 update the individual targets to free the
containing so_list objects.  Patch 14 updates solib-svr4 to free the
containing so_list objects and to add the acquire/release logic.
I have split this series this way to allow the individual maintainers
to approve/reject the individual patches, but if the series as a
whole is accepted then I will commit it as one chunk.

This is only a partial fix for PR 15590 because there is nonlinear
behaviour outside of the solib layer, in objects or symbols perhaps,
but this series removes everything quadratic from the solib side.
On my machine it gives a useful speedup with >2000 shared libraries:

  no of solibs      128     256     512     1024    2048    4096
  --------------------------------------------------------------
  baseline	      0       1       1        3      10      32
  patched	      0       0       1        3       6      24

FWIW I am not sure whether this solution is elegant or awful :)

Thanks,
Gary

[1] http://sourceware.org/bugzilla/show_bug.cgi?id=15590

-- 
http://gbenson.net/