Re: RFA: ia64 portion of libunwind patch

[David Mosberger <davidm@napali.hpl.hp.com>]

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