This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: ia64 portion of libunwind patch
>>>>> On Sat, 08 Nov 2003 18:40:49 -0500, Andrew Cagney <cagney@gnu.org> said:
Andrew> What I don't think "libunwind" should be doing is assuming
Andrew> that most efficient way to obtain specific elements of that
Andrew> unwind table is to read that table en-mass. Instead I think
Andrew> "libunwind" be careful to only request the specific memory
Andrew> locations that it needs - trust the client to supply the
Andrew> requests in the most efficient way possible.
That's good in some cases and bad in others. Based on gdb's needs, I
certainly could believe that there are some cases where incremental
reading would be faster. Perhaps a stronger argument for incremental
reading would be if it actually simplified the glue code that gdb
needs to talk to libunwind. I care a lot about making the glue code
as simple as possible and anything we can do to help there is of
interest to me.
Andrew> I should note that this has come up before, GDB encountered
Andrew> performance problems with a library that was trying to out
Andrew> smart a memory read bottle neck by slurping ever increasing
Andrew> chunks of unneeded memory. This made the performance
Andrew> problem worse not better - it was the volume of data and not
Andrew> the number of xfers that was the bottle neck.
Andrew> If we look at GDB with its 128k of unwind data. At 14*28
Andrew> byte requests per unwind, it would take ~300 unwinds before
Andrew> GDB was required to xfer 128k (yes I'm pushing the numbers a
Andrew> little here, but then I'm also ignoring the very significant
Andrew> locality of the searches).
Oh, but you're ignoring the latency effects. N 1-byte transfers can
easily be much slower than a single N-byte transfer.
Andrew> Scary as it is, GDB's already got a requrest to feltch a
Andrew> shared library image from the target's memory :-/.
That kind of throws your speed argument out of the water, though,
doesn't it? ;-)
Andrew> Provided the remote target knows the address of the unwind
Andrew> table, GDB should be able to find a way of getting it to
Andrew> libunwind.
OK, I still don't quite understand why this is a common and important
scenario. It strikes me as a corner-case which _occasionally_ may be
useful, but if that's true, a bit of extra latency doesn't seem like a
huge deal.
In any case, perhaps it is possible to add incremental reading support
by stealing a bit from one of the members in the "unw_dyn_table_info".
All we really need is a single bit to indicate whether the table-data
should be fetched from remote-memory. I'll think about it some more.
--david