RFA: ia64 portion of libunwind patch
Sun Nov 9 00:13:00 GMT 2003
> 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
"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!
More information about the Gdb-patches