HP-PA ABI issues - framepointer handling

[Jeffrey A Law]

  In message < 20001019191109.E6FB134D91@nile.gnat.com >you write:
  > I don't see how this will handle third party code, which at least for us
  > is a requirement.
Good luck.  None of GCC's stuff is going to handle 3rd party code.  That's
one of the toughest issues with building this stuff.  There's been multiple
long threads on this.  Basically it's not going to generally work.

  > ut in any case, since when did gcc make a point of NOT
  > following ABI's. I have always found it an advantage to stress that gcc
  > made a point of FOLLOWING ABI's and we have found this to be extremely
  > useful.
1. the ABI didn't exist when the code was written.

2. The ABI has fundamental incompatibilities with how GCC works (assumes
   you never have frame pointer).

3. This stuff doesn't belong in the ABI anyway.

4. The ABI places nasty restrictions on how you can generate code.

5. You can use something like dwarf2, then fall back to a slower, but
   more generic unwinder if dwarf2 stuff isn't available.  If you must
   unwind through qsort or 3rd party libraries, this is going to be
   unavoidable.

6. If you depend on the lame HP unwinding library you lose all hope of
   building cross compilers since that closed source library is only
   available hp-native.


Yes, I strongly believe in following ABIs where they affect interoperability
issues between code generated by multiple compilers.  I strongly believe this
stuff is outside that realm.

BUt as I've mentioned before, if you can find ways to follow those aspects
of the unwinding ABI without undue code performance regressions, feel free 
to do so.  I've already mentioned at least one thing (location of saved
registers) that falls into that category that you can start with.

jeff