Re: [RFC][patch] Avoid repeated calls to solib_add on initial attach.

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 20 July 2011 17:04:11, Paul Pluzhnikov wrote:
> On Wed, Jul 20, 2011 at 7:37 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> > On Friday 15 July 2011 21:52:09, Paul Pluzhnikov wrote:
> >> Greetings,
> >>
> >> Following up on my earlier "slow on high-latency links" message:
> >> http://sourceware.org/ml/gdb-patches/2011-07/msg00391.html ...
> >>
> >> Attached patch avoids calling solib_add twice when initially attaching
> >> inferior.
> >>
> >> I am not entirely happy about this patch, but don't have a better idea
> >> for a fix, and do want to avoid repeated rescans of the shared library list.
> >
> > Me neigher, apart from doing as the comment says:
> >
> >>   /* Sometimes the platform-specific hook loads initial shared
> >>        libraries, and sometimes it doesn't.  If it doesn't FROM_TTY will be
> >>        incorrectly 0 but such solib targets should be fixed anyway.  If we
> >>        made all the inferior hook methods consistent, this call could be
> >>        removed.  Call it only after the solib target has been initialized by
> >>        solib_create_inferior_hook.  */
> >
> > Or, making retrieving the dso list cheap enough to not care about the
> > multiple calls.  By e.g., caching more things, and making
> > target_read_string not super dumb (as you've yourself proposed).
> 
> I think DSO list with 4K entries and 200ms packet response time is not
> going to ever become cheap enough. 

Yeah.  

> Fixing all inferior hook methods to be consistent and always load
> initial DSO list sounds promising, but has the practical problem: I don't
> have access to many systems.  I'll check what I can do there ...

I'm not certain of the amount of work here.  I'm okay with
your approach as fallback (you should make the counter
unsigned to avoid undefined signed overflow).

> 
> > Can you give a try on the attached patches and see how much
> > a difference they make for you?
> 
> Thanks, I'll try them.
> 
> > Patch 2 has the most dramatic affect;
> 
> Yes, I've already tried equivalent patch (except I set the default
> size to 128), and (as expected) it did make a big difference.
> 
> Going back to the new packet proposal to speed up target_read_string;
> do you have any additional comments on
> 
>   qStr {addr},{maxlen},{terminator}
> 
> format?  Should {terminator} be optional? Should I avoid it altogether
> (it doesn't solve any current problem, so perhaps it's over-design) ?

We considered a packet like this too, but decided that bumping
target_read_string first and seeing if anything breaks would be
better.  Haven't heard back of any breakage or slowdown so far.
I propose we do the same upstream.

-- 
Pedro Alves