Re: HP-PA ABI issues - framepointer handling

[dewar at gnat dot com (Robert Dewar)]

<<No, no other software relies on this stuff.
>>

That's a rather strong statement, which assumes familiarity with all
software anyone ever wrote for this system :-) For example, if OC
Systems has a port of APROBE for the HPUX, it will almost certainly
depend on the unwinding mechanism.

Note that the circuitry in the "lame HP stack unwinder" is trivial.
The format of the traceback information is very well documented, and
anyone can easily reproduce the processing in this library (that is
probably what we intend to do, we are not sure yet). So really there
is no big issue with cross compilers here (and of course if you
are cross-compiling you don't necessarily need the library on the
host machine anyway). 

An interesting note is that this is the only machine so far where we
have encountered this kind of clash between what gcc generates and
the system unwind conventions.

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.

Anyway, as I said earlier, we continue to investigate this issue, and
will report back when we have a full picture of what is involved,
including some performance data.

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

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.