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

[Pedro Alves <pedro@codesourcery.com>]

On Wednesday 20 July 2011 17:44:43, Paul Pluzhnikov wrote:
> On Wed, Jul 20, 2011 at 9:35 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> 
> >>   qStr {addr},{maxlen},{terminator}
> ...
> > 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.
> 
> But do you have any targets where reading individual words is slow?

You mean slower than reading ~16 words?  I doubt there's any where
it matters over the latency saved for the current callers of
target_read_string.  Maybe it would matter if target_read_string
and read_string were merged.  I don't object to the new packet;
I'm merely suggesting avoiding work until proven necessary.  The
idea is off course sound.

> I don't know about any such targets first-hand, but I've heard that
> JTAG reading could be exceedingly slow.

We use a bunch of different probes, and so do our customers.  I
don't know offhand which are slow, but they're there for sure.

> Another possible alternative is to make this a run-time parameter:
> 'maintenance set string-read-size 64' or some such. Default to 64 and
> let JTAG people dial it down if it ever becomes a problem for them?

I don't envision this being necessary, but I've certainly been
wrong before...

-- 
Pedro Alves