Re: RFA: ia64 portion of libunwind patch

[Andrew Cagney <cagney@gnu.org>]

>   Andrew> "at least not locally".  The unwind info can always be found
>   Andrew> in the target's memory.
> 
>   Andrew> There are two choices here: - make the interface more remote
>   Andrew> friendly - just ignore the issue until someone complains
> 
> Can you make it so that the local ELF image is used _when_ it's
> available?

"libunwind" should assume that GDB will fill each memory request using 
the most efficient [correct] source available.  One potential source 
being the local ELF image.  If this isn't happening then GDB has 
something to fix (significantly, "libunwind" should resist the 
temptation to work around any such problems).

What I don't think "libunwind" should be doing is assuming that most 
efficient way to obtain specific elements of that unwind table is to 
read that table en-mass.  Instead I think "libunwind" be careful to only 
request the specific memory locations that it needs - trust the client 
to supply the requests in the most efficient way possible.  I should 
note that this has come up before, GDB encountered performance problems 
with a library that was trying to out smart a memory read bottle neck by 
slurping ever increasing chunks of unneeded memory.  This made the 
performance problem worse not better - it was the volume of data and not 
the number of xfers that was the bottle neck.

If we look at GDB with its 128k of unwind data.  At 14*28 byte requests 
per unwind, it would take ~300 unwinds before GDB was required to xfer 
128k (yes I'm pushing the numbers a little here, but then I'm also 
ignoring the very significant locality of the searches).

> I personally never used gdb without specifying an
> executable file (I'm not even sure how that works), so I guess I'm
> willing to wait until someone complains (note that it's not as easy as
> simply setting table_data to NULL, because there would be no way to
> calculate the address of the unwind-table entry, so I'm not sure what
> you want could be done without breaking the existing API).

Scary as it is, GDB's already got a requrest to feltch a shared library 
image from the target's memory :-/.  Provided the remote target knows 
the address of the unwind table, GDB should be able to find a way of 
getting it to libunwind.

>   Andrew> Hmm, a good question to ask is "how cross debug friendly" is
>   Andrew> libunwind.?  If its anything like libthread-db then this
>   Andrew> discussion is mute.
> 
> I don't know what the issue with libthread-db is, but libunwind is
> designed to be cross-debug friendly.  It's a feature that gets
> regularly tested, e.g., as part of libunwind built into HP's ia64
> simulator (which runs fine on x86 linux, for example).  In theory,
> libunwind also support multiple unwind targets in the same binary, but
> this hasn't been tested much so far (but I also have no reason to
> believe that it doesn't work).

"all of the above", this is very good news!

Andrew