Re: RFA: ia64 portion of libunwind patch

[Andrew Cagney <ac131313 at redhat dot com>]

> On Thu, 30 Oct 2003 14:18:20 -0500, "J. Johnston" <jjohnstn@redhat.com> said:
>
>   Andrew> Can you expand a little here on how this function interacts
>   Andrew> with libunwind?
>
> It is used by libunwind to access the unwind info.  This is read-only
> data that part of the ELF image and (at least for ia64) is also mapped
> into the target space.

Ok.  The target vector consists of a number of stratum.  When a memory 
request is sent to the target it is responsible (note, minus bugs) for 
servicing the request using the most applicable stratum.  For instance, 
given a core file, modified memory sections are supplied by the 
process/corefile stratum, while read-only sections are supplied by the 
file/executable stratum.

>   Andrew> I can see that its reading in data, but is that data found
>   Andrew> in the target's space?
>
> It could be found there.
>
>   Andrew> If it is then the info should be pulled direct from the
>   Andrew> target and the BFD/objfile should not be used.  The relevant
>   Andrew> target stratum can then re-direct the request to a local
>   Andrew> file.
>
> I agree, it sounds like this would be a much cleaner way of doing it.

As they say, make it work correctly, then make it work fast :-)  If 
target i/o gets to be a problem, we [gdb] get to fix the target stack.

>   Andrew> I'm also wondering if the unwind code (probably impossible I
>   Andrew> know) could use a callback to request the memory rather than
>   Andrew> require an entire buffer.
>
> 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.

Given a PC, how is the table located?  I see the change does roughly:
  pc -> section -> objfile -> BFD -> unwind segment -> paddr/size?
(could it look up the BFD's .IA_64.unwind_* sections instead?)
I guess initially, it could just use the paddr/size to pull the memory 
from "current_target"?

I suspect though that long term a memory request callback will prove 
more effective - it would avoid locking GDB into a model that requires 
it to cache full and contigous unwind sections.  Using a back of 
envelope caculation (GDB appears to have a log2 (128k of unwind section 
/ 24) = ~14) I'm guessing that the binary search involves about 14 
fetches and provided they are serviced from a cache they will be very 
efficient.

Andrew