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