Re: RFA: ia64 portion of libunwind patch

[David Mosberger <davidm at napali dot hpl dot hp dot com>]

>>>>> On Fri, 07 Nov 2003 19:27:54 -0500, Andrew Cagney <ac131313@redhat.com> said:

  >> Because it may not have the elf binary (at least not locally),
  >> and it
  >>> may not have debug info.  People still expect GDB to do
  >>> something reasonable in those cases.

  >> I'm a little bit puzzled about why we wouldn't have the elf
  >> binary...

  >> But, assuming for the moment that we do, we'll definitely have
  >> the unwind info since it's mandated by the ABI.

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

	--david