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

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Gary" == Gary Benson <gbenson@redhat.com> writes:

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

I'm having a bit of trouble wrapping my head around this patch.  I
wonder why any copying at all is needed.

My current understanding is that the problem is a combination of (1)
lack of reference counting for so_list, and (2) the fact that the
current_sos method returns a linked list, and so returning an so already
in use is impossible, since it already has a 'next' field that must be
preserved.

(1) could perhaps be fixed with a reference count biased by 1 (that is,
the number of references == 1 + solib->refc).  That way, all the targets
that use zalloc to allocate would do the right thing without change.

(2) could be fixed by using a VEC; either invasively by changing all the
solib implementations, or less so by adding a new current_sos_vec that
is used in preference if it is not NULL.  Then solib-svr4 would
implement this new method.

I feel as though I am missing something, though.

Tom