[M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?

[Jay]

I believe libunwind/libgcc_s applies pretty broadly and address all non-NT platforms. I believe NT/non-x86 is documented enough. NT/x86 will take more research.


I also believe generating C++ is a good option, or Win32-specific C.


I do have the alloca+setjmp work finally almost done, slightly more work than I earlier realized & would like to get it in first, then optimize it in the C backend (the C backend specifically should declare a setjmp.h declared jmp_buf w/o alloca), & then look more into the "unwind" options. 


 - Jay

On Jul 30, 2015, at 7:27 AM, "Rodney M. Bates" <rodney_bates at lcwb.coop> wrote:

> 
> 
> On 07/29/2015 11:36 PM, Jay K wrote:
>> On the last point -- I'm willing to generate C++ instead of C. Does that help?
>> I think it probably does.
>> 
>> 
>> On Win32 I could still generate C. And, not important, but Ultrix, OSF/1, and OpenVMS I
>> think all support what Win32 support -- not a coincidence..
>> 
>> 
>> One thing I'm missing is I don't know really know how exceptions are lowered currently.
>> Like, what does the runtime data look like for the "filtering".
>> I should know better..
>> 
>> 
>> I think we can also essentially claim all targets have a stack walker.
>> One way or another -- libunwind, NT RtlUnwindEx, etc.
> 
> Really?  That would be great news.  If it really applies to them all, wouldn't
> the jmpbuf problem just go away?
> 
>> 
>> 
>>  - Jay
>> 
>> 
>> 
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------!
> ---
>> Subject: Re: [M3devel] higher level M3CG modeling of jmpbuf/setjmp/longjmp or exception handling?
>> From: hosking at purdue.edu
>> Date: Thu, 30 Jul 2015 14:04:14 +1000
>> CC: m3devel at elegosoft.com
>> To: jay.krell at cornell.edu
>> 
>> I agree that lifting the abstraction level for exceptions in the front-end would be a good idea.
>> It would allow us to more effectively make use of specialized target exception handling, e.g., from LLVM.
>> That suggests we at least lift to the LLVM level of abstraction, but I don’t know how easy that will be to generate from for the C backend.
>> 
>>    On Jul 30, 2015, at 10:38 AM, Jay K <jay.krell at cornell.edu <mailto:jay.krell at cornell.edu>> wrote:
>> 
>>    I don't have one precise proposal, but somehow,
>>    jmpbuf/setjmp/longjmp should be represented in a higher level in m3cg
>>    or maybe "even higher level", exception handling.
>> 
>> 
>>    There are multiple optimization opportunties and multiple
>>    opportunities to move/remove target-dependent code.
>> 
>> 
>> 
>>    In particular m3middle/m3front should not know jmpbuf size.
>>    Generated C should not have jmpbuf sizes embedded in it.
>> 
>> 
>>    gcc has a "builtin" jmpbuf/setjmp/longjmp notion, for use by exception
>>    handling, that llvm replicates, that is optimized, like to not
>>    save/restore unused registers.
>> 
>> 
>>    Or, yes, there is my alloca proposal, which doesn't solve as much, but does help.
>> 
>> 
>>    In particular, the C backend just wants to know something is a "jmpbuf"
>>    so it can #include <setjmp.h> in the generated code and produce a
>>    jmpbuf instead of an array of bytes and call setjmp/longjmp or _setjmp/_longjmp.
>> 
>> 
>>    Or even better, a C++ backend wants to somehow module Modula-3 exceptions
>>    as C++ exceptions.
>> 
>> 
>>    Or, possibly, the Win32 C backend could model Modula-3 exceptions using
>>    "structured exception handling" -- advantage over C++ exceptions is portability
>>    to kernel mode.
>> 
>> 
>>    Thoughts?
>>      - Jay
>> 
>> 
>>    _______________________________________________
>>    M3devel mailing list
>>    M3devel at elegosoft.com <mailto:M3devel at elegosoft.com>
>>    https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
>> 
>> 
>> 
>> 
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> 
> -- 
> Rodney Bates
> rodney.m.bates at acm.org