Re: Targets that don't support exception handling

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

  In message <34F8901E.4A49314D@btinternet.com>you write:
  > I did try with some effort to get some modifications into gcc 2.8.0
  > to support exception handling for RISC OS, but Kenner mentioned that
  > more of a implementation change within gcc would be required to
  > accommodate RISC OS. There are two main reasons:
  > 
  >   1. gcc/egcs assumes that the stack can be unwinded with very few
  > instructions. RISC OS can use both a non-contiguous and a contiguous
  > stack and requires a function with 30 instructions to unwind the stack.
  > It is impossible to inline this function.
?  Where/Why/How does gcc/egcs make the assumption that the stack
can be unwound with a few instructions?


  >   2. gcc/egcs makes assumptions about the stack and frame pointer that
  > are plainly incompatible with the RISC OS/APCS standard.
Such as?  Without details we can't even guess what assumptions you're
referrnig to.


  > I was hoping to release a version of egcs for RISC OS users that
  > provided a C++ compiler but it seems that egcs now only supports
  > targets that support exception handling. I removed the exceptions
  > support from libgcc and have managed to get libio compiled but 
  > I've just stumbled across exceptions in libstdc++
  > 
  > It seems that I was obviously not paying attention when the
  > transitional phase was made to support exception handling.
  > Am I the only person who is trying to get a C++ port running on
  > a target that doesn't currently support exception handling ?
Can you use the builtin setjmp/longjmp based EH mechansisms? That's
what's typically done for targets that don't currently support
the dwarf unwinder version.

If not, and you have a target which truely breaks fundamental
assumptions about how EH works, then you're either going to have
to help reimplement EH, keep local hacks to turn it off, or something
along those lines..




jeff