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

[Paul Pluzhnikov <ppluzhnikov at google dot com>]

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.  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 ...

> 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) ?

Thanks,
-- 
Paul Pluzhnikov