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.