Re: HP-PA ABI issues - framepointer handling

[Jeffrey A Law <law at cygnus dot com>]

  In message <20001020142015.0B44C34D87@nile.gnat.com>you write:
  > Note that the circuitry in the "lame HP stack unwinder" is trivial.
  > The format of the traceback information is very well documented,
The traceback information HP provides is painfully inadequate for backtracing
optimized code.  You're welcome to try and use it, or you can trust 8 years
of development experience on this platform (including writing code to
read and interpret HP's unwind tables).

  > Yes, it may be possible to use Dwarf-2 tables, if we ensure that GNAT
  > , or rather GCC< generates appropriate indicators of what is used, but
  > the Dwarf-2 tables are a lot larger than the HP unwind information.
Yes they are probably larger, but they actually provide the unwinder with
the information it needs.

  > By the way, I have no objection to violating the ABI for performance
  > reasons under control of a switch, for example, -fomit-frame-pointer
  > is quite a reasonable option on the x86, even though it clearly violates
  > the ABI (and indeed results in a lot of debuggers not working).
No, using/not using a frame pointer is not an ABI issue.  Whether or not
a frame pointer is used strictly affects the code within a function.  
Functions with or without frame pointers can call other functions with or
without frame pointers.

  > One general point here is that you cannot fully rely on gdb being able to
  > do debug tracebacks, because in the real world, especially in the embedded
  > world, you run into closed world hardware emulators which have their own
  > idea of debugging from system standard debugging information, and that's
  > another reason to conform closely with the system ABI.
Yes, I'm well aware of these issues.  I've been doing embedded work in gcc and
gdb for a while...

jeff