Re: sjlj-exceptions ICE. simplified test case

[Geoff Keating <geoffk at geoffk dot org>]

Mark Mitchell <mark@codesourcery.com> writes:

> --On Wednesday, April 26, 2000 11:04:26 AM -0600 Tom Tromey 
> <tromey@cygnus.com> wrote:
> 
> >>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
...
> > Mark> However, we should all be aware that every feature, even ones
> > Mark> that already exist, have a substantial maintenance cost.
> > Mark> Perhaps, from the point of view gcj development, sjlj exceptions
> > Mark> "just work".  But, Richard just spent some time tracking down
> > Mark> bugs that only occurred in that context, and lots of other
> > Mark> people have had to debug similar problems in the past.  Some of
> > Mark> those resources could probably have been devoted to implementing
> > Mark> the DWARF2 unwind support for a few more targets.
> >
> > However, it isn't that simple either.  Resources aren't really
> > completely fluid like that.  And I gather that porting the remaining
> > targets to table-based exceptions isn't being done.  I think Andrew's
> > point is that we all agree that table-based exceptions are the way to
> > go.  But ditching them before they are more completely implemented
> > would be a real problem.
> 
> Wow, I don't really remember this conversation.  Yes, there is clearly
> a tension between inconveniencing people whose targets currently only
> do SJLJ and the people who have to maintain SJLJ, or touch code where
> it shows up.  It's a balancing act...

An example of a port which currently requires SJLJ and which can't
easily be ported to use range-table-based EH is stormy16-elf.  It has
16-bit pointers, including function pointers, but a 32-bit program
counter.

-- 
- Geoffrey Keating <geoffk@geoffk.org>