Re: [draft patch 0/6] Split FYI and some review notes

Gary Benson
2013-03-14T18:43:42Z

Jan Kratochvil wrote:
> On Mon, 11 Mar 2013 15:25:13 +0100, Aleksandar Ristovski wrote:
> > On 13-03-10 05:07 PM, Jan Kratochvil wrote:
> > > Do not run get_hex_build_id quadratically - currently for each
> > > library you open and scan maps/smaps again. Probably the best
> > > approach is to scan all l_ld addresses from r_debug first, then
> > > qsort them and then linearly match them to the maps/smaps
> > > entries. I am not sure but I guess they still should be
> > > returned to GDB in their original order from r_debug for some
> > > backward and solib-svr4.c compatibility. Also Gary Benson is
> > > working on incremental shlib transfers from gdbserver so that it
> > > does not clash too much (it will anyway). While just quadratic
> > > computation would be in real world acceptable all the
> > > open/read/close syscalls I find really needlessly expensive.
> >
> > I thought it would be an overkill to make it any more
> > optimal. Ideal situation would be to send "library loaded"/
> > "library unloaded" events instead of sending the whole list
> > each time.
> >
> > But sure, I'll do the qsort.
>
> Particularly this shared library list handling has been proven to
> be performance critical. All the performance improvements by Gary
> Benson target this issue, including sending the '"library loaded"/
> "library unloaded" events' (being worked on).

It's definitely performance critical on the GDB side. There are
people out there debugging apps with 4000+ shared libraries, and
that exposes all kinds of issues :)

Per your suggestion of gdbserver sending events... I've spent some
time thinking about this. I think the direction of the protocol is
correct, in that GDB asks for the library list when it wants it.
What exactly is transferred is open to change (whole list vs deltas)
but I don't know whether anybody is actually having issues with
performance stemming from the size of the transferred list. I can
certainly imagine scenarios where it would be the bottleneck, but
I don't know if these exist in the real world.

Note that since Tom's ambiguous linespec work went in GDB needs to
update its list at every change. You could seriously speed things up
if you could eliminate this need--I considered making it asynchronous
at one point, but couldn't get around it.

> Ccing Gary as the qsort by l_ld in gdbserver apparently has to clash
> with his patch being cooked.

I think they do need to be transferred to GDB in the order they were
read from r_debug. Thank you Jan for spotting this.

Thanks,
Gary

--