llvm dev - Dec 2016 - setjmp/longjmp and volatile stores, but non-volatile loads

On 30/09/16 20:10, Reid Kleckner wrote:
> On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at
watlock.be
> <mailto:jonas-devlists at watlock.be>> wrote:
>
>     So, can I use invoke and landingpad without using any of the other
>     exception handling intrinsics? (in combination with a dummy personality
>     function) Or will LLVM in all cases insist on using ehframe
information,
>     a (C++-)ABI-compliant personality function, and possibly linking in
>     parts of its own runtime that depend on this information being correct?
>
>
> I would say that the coupling between LLVM generated code and the HP
> unwind interface is pretty low. The only call LLVM emits is to
> _Unwind_Resume, so you would have to go into
> llvm/lib/CodeGen/DwarfEHPrepare.cpp and teach LLVM what you want it to
> call in your runtime for your EH personality.
I thought I had finally figured out how to dance around this, but while 
I got close, it's not perfect :/

Recap: we use setjmp/longjmp for our exception handling on all platforms 
in our regular (non-LLVM) code generators. I'd like to use the same 
infrastructure with the LLVM code generator for code interoperability 
purposes (the LLVM SjLj personality is not binary-compatible with our 
existing setjump/longjump buffers).

What I did was:
1) create a dummy personality function in our run time library that 
basically always says "no, this frame does not wish to handle this 
exception nor does it have any clean-up code", and specify it as 
personality function for any function that deals with exceptions
2) create a BBL with a landingpad and no other code at the end of every 
try-block
3) in the try-blocks themselves, replace all calls with invokes that 
unwind to this landingpad BBL

Then, I tried the following:
a) if the longjmp for the try-block is taken (i.e., the setjmp right 
before the try-block returns a non-zero value), jump to the landingpad BBL.

-> Problem: LLVM does not allow regular jump edges to landingpad BBLs

b) since the landingpad is empty anyway and falls through into the next 
BBL (which contains the start of our actual exception handling code), 
jump to that next BBL from setjmp.

-> Problem: even though I do not insert code in the landingpad BBLs, 
LLVM may still add code to them, e.g. for (LLVM-created) phi-nodes.

I can't think of any solution to deal with this :/


Jonas

Jonas Maebe via llvm-dev wrote:
> Then, I tried the following:
> a) if the longjmp for the try-block is taken (i.e., the setjmp right
> before the try-block returns a non-zero value), jump to the landingpad BBL.
> 
> -> Problem: LLVM does not allow regular jump edges to landingpad BBLs
> 
> b) since the landingpad is empty anyway and falls through into the next
> BBL (which contains the start of our actual exception handling code),
> jump to that next BBL from setjmp.
> 
> -> Problem: even though I do not insert code in the landingpad BBLs,
> LLVM may still add code to them, e.g. for (LLVM-created) phi-nodes.
Actually, there's another —even more fundamental— problem: the longjmp
will always restore the non-volatile registers to the contents they had
at the start of the try-block, which is not what LLVM expects when
entering an SEH-based landing pad.


Jonas

On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev
wrote:
> Recap: we use setjmp/longjmp for our exception handling on all platforms in
> our regular (non-LLVM) code generators. I'd like to use the same
> infrastructure with the LLVM code generator for code interoperability
> purposes (the LLVM SjLj personality is not binary-compatible with our
> existing setjump/longjump buffers).
I'm moderately sure that SjLj presonality does not use system longjmp
and does not claim to be binary compatible either. It usees the
intrinsics.

Joerg

On 19/12/16 12:16, Joerg Sonnenberger via llvm-dev
wrote:
> On Sun, Dec 18, 2016 at 02:23:01PM +0100, Jonas Maebe via llvm-dev wrote:
>> Recap: we use setjmp/longjmp for our exception handling on all
platforms in
>> our regular (non-LLVM) code generators. I'd like to use the same
>> infrastructure with the LLVM code generator for code interoperability
>> purposes (the LLVM SjLj personality is not binary-compatible with our
>> existing setjump/longjump buffers).
>
> I'm moderately sure that SjLj presonality does not use system longjmp
> and does not claim to be binary compatible either. It usees the
> intrinsics.
I know, that's why I was trying to combine our own setjmp/longjmp-based 
exception handling helpers (for binary compatibility) with a bare 
minimum of LLVM's generic exception handling infrastructure
("invoke"
and "landingpad {i8 *, i32} catch i8* null", to ensure that LLVM's
control flow analysis is correct).

You can see an example of the result at http://pastebin.com/77jVJJSu, 
which is the try/except-statement of the following program:

{$q+}
var
   i1: int64;
   caught: boolean;
begin
   i1:=low(int64);
   caught:=false;
   try
     i1:=i1-1;
   except
     caught:=true;
   end;
end.


However, that approach does not appear to be possible in the end because 
of the reasons mentioned in my previous mail.


Jonas

On Sun, Dec 18, 2016 at 11:58 PM, Jonas Maebe <jonas-devlists at
watlock.be>
wrote:
>
> Actually, there's another —even more fundamental— problem: the longjmp
> will always restore the non-volatile registers to the contents they had
> at the start of the try-block, which is not what LLVM expects when
> entering an SEH-based landing pad.
>
The SjLjEHPrepare pass tries to deal with this by demoting all values live
across EH edges to the stack. This should also eliminate those phis from
landingpad blocks. Check
out TargetPassConfig::addPassesToHandleExceptions() and make sure you run
that pass.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161221/ed5759b0/attachment.html>