Re: RFA: ia64 portion of libunwind patch

[Andrew Cagney <ac131313@redhat.com>]

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

It's easy to play with the numbers here. Ex:  The remote protocol 
typically caps each transfer at ~1k.  So that would be 128 (xfer all) vs 
14 (xfer needed) so it would still be faster.

More seriously.  If problems are identified in the remote protocol, GDB 
should fix them.  It is important though, that its clients don't program 
around perceived performance problems and in doing so create artifical 
loads.  As my previous e-mail mentioned, GDB's already seen one example 
of that - a library demanding ever increasing amounts of data in attempt 
to work around an io throughput bottle neck.

>   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? ;-)

The extraction will need to be done very carefully so only required data 
is read.

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

It would be appreciated.  My suggestion was to use memory reads when the 
unwind table pointer was NULL.  However, anything would help.

Andrew