Re: RFA: ia64 portion of libunwind patch

[Andrew Cagney <ac131313@redhat.com>]

> On Fri, 31 Oct 2003 15:46:19 -0500, Andrew Cagney <ac131313@redhat.com> said:
> 
> 
>   >>  The way the libunwind interface works nowadays, the only
>   >> buffering that is strictly needed is for the unwind info of the
>   >> procedure being looked up (which usually has a size of the order
>   >> of tens of bytes).  But this would require doing a binary search
>   >> on the unwind-table in the target space, which might be rather
>   >> slow (there is one 24-byte entry in this table per procedure).
>   >> Thus, it might be easier (and certainly faster) to buffer the
>   >> unwind table inside gdb.
> 
>   Andrew> Given a PC, how is the table located?  I see the change does
>   Andrew> roughly: pc -> section -> objfile -> BFD -> unwind segment
>   Andrew> -> paddr/size?
> 
> That's about right.
> 
>   Andrew> (GDB appears to have a log2 (128k of unwind section / 24) =
>   Andrew> ~14) I'm guessing that the binary search involves about 14
>   Andrew> fetches and provided they are serviced from a cache they
>   Andrew> will be very efficient.
> 
> Yup.

Would it be possible to define the interface so that, when 
dip->u.ti.table_data is NULL, the code just fetches values from memory 
using the memory callbacks?  i.e., don't require GDB to fetch the entire 
table but instead fetch the bits that are needed.

Andrew