Re: PATCH: sjlj exceptions

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

> On Fri, Oct 27, 2000 at 04:21:27PM -0400, John David Anglin wrote:
> > There are two separate parts to the fix.  The first part is to define
> > a nonlocal goto label after the setjmp call when a library version of
> > setjmp.  This fixes the basic block reordering problem noted in this post:
> > <http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00526.html>.
> 
> This is surely wrong.

However, it appears to work.  

If you are correct, then there is another problem in bb-reorder that this
inadvertantly works around.  I tried DONT_USE_BUILTIN_SETJMP because the code
for this mode didn't generate a nonlocal goto label and this was the main
difference as far as I could see between the libcall and builtin setjmp
exception code.  Originally, I hoped that I could delete the nonlocal goto
label code from the builtin setjmp code.  However, I now believe that
I was wrong in hoping that the labels were unnecessary.

This is the comment in builtins.c about this:

 /* Tell flow about the strange goings on.  Putting `lab1' on
    `nonlocal_goto_handler_labels' to indicates that function
    calls may traverse the arc back to this label.  */

My assumption is that flow needs to know that the current function
has an entry point following a setjmp, irregardless of whether or not
it is for exceptions.  The setjmp remains in effect until the function exits
or another setjmp is traversed which uses the same jump_buf.  This places
constraints on how blocks can be reordered.

The situation is more constrained for exception usage.  In this case,
the setjmp is only in effect for its exception region.

> The only correct way to fix the edge count problems in sjlj exception
> handling is to partition the non-local goto support such that we can
> keep track of which labels are used for actual non-local gotos and
> which are exception handling targets.  To-date, no one has cared,
> since dwarf2 exceptions are so much cleaner.

Yes.  What is not clear is the relative efficiency of the setjmp versus
inline unwind code when the dwarf2 mechanism isn't available.  If there
wasn't much of a penalty, maybe another option would be to dump the
sjlj mechanism.  I don't think legacy issues are a major problem since
this has never worked well, at least on the pa.

The function expand_builtin_setjmp is the wrong place to generate exception
labels unless the sole purpose of this function is for exceptions.  It
probably shouldn't be a builtin if this is the case.

> > The second part is to set current_function_calls_setjmp = 1.  This causes
> > the gcse pass to punt, preventing the memory buildup.  I think it is also
> > necessary to ensure that registers are properly saved.
> 
> This should only be done for DONT_USE_BUILTIN_SETJMP, and it
> is only needed if the target defines NON_SAVING_SETJMP.  I.e.
> it is a problem, but not for pa.

This will take some more testing however I wasn't convinced that registers
for non local variables were being saved correctly with the builtin
setjmp.  I think current_function_calls_setjmp gets set in any function
that calls setjmp or its cousins in C code (see line 3174 of calls.c), and
it doesn't depend on whether or not NON_SAVING_SETJMP is defined.  As I noted,
current_function_calls_setjmp has other side effects such as that on the
NOTE_INSN_EH_REGION_[BEG,END] notes and causing the gcse pass to punt.

I think Jeff wrote the gcse pass.  Maybe he can explain why it can't
construct an accurate CFG in functions which use setjmp.

Why should we lie about using setjmp in this case?

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)