zero cost exception handling

[demoitem]

I just pushed a branch, zcxh, zero cost exception handling for the
target amd64_linux based on libunwind. Feel free to comment,
try out or find bugs. I'll merge it into master in a couple of weeks
if no showstoppers. To be clear, current sjlj exception handling
is unaffected on all targets. You have to define M3_USE_STACK_WALKER
in AMD64_LINUX config and recompile the runtime to see any effect.
Only the GCC and llvm backends are supported. Oh, and you may have
to install the libunwind libraries.

[VictorMiasnikov]

Thank You! I going to create release based on "zcxh" branch

[VictorMiasnikov]

Technician: Can You merge "master" branch into "zcxh" branch? ( as next / ( current + one) step)
^^^^^^^^^^^^^^^^^^^^
Best create another combo branch

[VictorMiasnikov]

P.S.

(
Before this
} > merge "master" branch into "zcxh" branch into "combo branch"
)

And please see
#1028

[VictorMiasnikov]

(
On 2022-10-18 sub-issue fixed. Please see:
#1102 (comment)
)

What is "M3CG version stamp" ?

https://github.com/VictorMiasnikov/cm3/actions/runs/3190634848/jobs/5206004669

m3cc (aka cm3cg) failed compiling: TimePosix.ic
new exporters -> recompiling DatePosix.i3
cm3cg: fatal error:  *** bad M3CG version stamp (0x110), expected 0x120
compilation terminated.
  m3_backend => 1
m3cc (aka cm3cg) failed compiling: DatePosix.ic
new exporters -> recompiling Text.i3
cm3cg: fatal error:  *** bad M3CG version stamp (0x110), expected 0x120
compilation terminated.
  m3_backend => 1
m3cc (aka cm3cg) failed compiling: Text.ic
compilation failed => not building library "libm3core.a"

[VictorMiasnikov]

Please, see some "1/2 binary" in
https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag

P.S.

2022-10-07:
It has been tested on AMD64_NT. There is "all good". ( Of course, it is only "regression test" )
^^^^^^^^^^^^^^ Sorry -- see later

[VictorMiasnikov]

Please, see some "1/2 binary" in https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag

P.S.

2022-10-07: It has been tested on AMD64_NT. There is "all good". ( Of course, it is only "regression test" )

Sorry: may be, I see regression:

https://github.com/VictorMiasnikov/cm3/actions/runs/3190726991/jobs/5206462414
AMD64_NT / build
failed 5 days ago in 12m 45s

cd D:\a\cm3\cm3\m3-ui\ui
D:\a\cm3\install\cm3\bin\cm3.exe -build -DBUILD_DIR=AMD64_NT -DROOT=D:\a\cm3\cm3 -DTARGET=AMD64_NT -DM3_BACKEND_MODE=C
--- building in AMD64_NT ---

ignoring ../src\m3overrides

new source -> compiling Pixmap.i3
new source -> compiling TrestleComm.i3

 ( . . .)

new source -> compiling TextVBT.m3


***
*** runtime error:
***    <*ASSERT*> failed: NOT is_const 
***    file "../src/values/Module.m3", line 1045
***

and

https://github.com/VictorMiasnikov/cm3/actions/runs/3190726991/jobs/5206462316
AMD64_MINGW / build

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
0xe7dc1fd600  0x7ff7703207d7  LoadGlobalAddr + 0x191 in ../src/values/Module.m3
0xe7dc1fd680  0x7ff770388ef9  InnerCompile + 0x188 in ../src/exprs/ArrayExpr.m3
0xe7dc1fd6f0  0x7ff770388288  Compile + 0x226 in ../src/exprs/ArrayExpr.m3
0xe7dc1fd740  0x7ff77037502b  Compile + 0xe7 in ../src/exprs/Expr.m3
0xe7dc1fd780  0x7ff7703962e8  Compile + 0x8f in ../src/exprs/ConsExpr.m3
0xe7dc1fd7d0  0x7ff77037502b  Compile + 0xe7 in ../src/exprs/Expr.m3
.........  .........  ... more frames ...

P.P.S.

More modern commit:

https://github.com/VictorMiasnikov/cm3/actions/runs/3220355954/jobs/5266952169
I386_NT / build (integrated)

new source -> compiling TextVBT.m3


***
*** runtime error:
***    <*ASSERT*> failed: NOT is_const 
***    file "../src\values/Module.m3", line 1045
***

Stack trace:
   FP         PC      Procedure
---------  ---------  -------------------------------
 0x4fe8a4   0xa9a4b7  LoadGlobalAddr + 0x113 in ../src\values/Module.m3
 0x4fe8d4   0xbbdcae  InnerCompile + 0xf3 in ../src\exprs/ArrayExpr.m3
 0x4fe900   0xbbd46e  Compile + 0x14f in ../src\exprs/ArrayExpr.m3
 0x4fe924   0xba539e  Compile + 0xa8 in ../src\exprs/Expr.m3
 0x4fe944   0xbec7f9  Compile + 0x5c in ../src\exprs/ConsExpr.m3
 0x4fe968   0xba539e  Compile + 0xa8 in ../src\exprs/Expr.m3
 0x4fe9e4   0xbb1266  GenStruct + 0x67a in ../src\values/Formal.m3
 0x4fea18   0xbaf67d  EmitArg + 0x260 in ../src\values/Formal.m3
 0x4fea40   0xaef01d  EmitRightToLeft + 0xe0 in ../src\types/UserProc.m3
 0x4fea6c   0xaeefab  EmitRightToLeft + 0x6e in ../src\types/UserProc.m3
.........  .........  ... more frames ...

P.P.S.

2022-10-18: Possible fixed . . . Need more testing

2022-10-19:

"Combo branch":

https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20221019_15-00

[demoitem]

That is a strange error. It's hard to see it being related to exception handling changes.

…

On Tue, 11 Oct 2022 at 01:41, VictorMiasnikov ***@***.***> wrote: Please, see some "1/2 binary" in https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag P.S. 2022-10-07: It has been tested on AMD64_NT. There is "all good". ( Of course, it is only "regression test" ) Sorry: may be, I see regression: https://github.com/VictorMiasnikov/cm3/actions/runs/3190726991/jobs/5206462414 AMD64_NT / build failed 5 days ago in 12m 45s cd D:\a\cm3\cm3\m3-ui\ui D:\a\cm3\install\cm3\bin\cm3.exe -build -DBUILD_DIR=AMD64_NT -DROOT=D:\a\cm3\cm3 -DTARGET=AMD64_NT -DM3_BACKEND_MODE=C --- building in AMD64_NT --- ignoring ../src\m3overrides new source -> compiling Pixmap.i3 new source -> compiling TrestleComm.i3 ( . . .) new source -> compiling TextVBT.m3 *** *** runtime error: *** <*ASSERT*> failed: NOT is_const *** file "../src/values/Module.m3", line 1045 *** — Reply to this email directly, view it on GitHub <#1095 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABALZX6WZFBVF3TAFKYEKN3WCQTKTANCNFSM6AAAAAAQ4EEQF4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[VictorMiasnikov]

On Tue, 11 Oct 2022 at 01:41, VictorMiasnikov @.***> wrote: Please, see some "1/2 binary" in
https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag

That is a strange error. It's hard to see it being related to exception handling changes.

Now I think: "What is next step"?

P.S. Of course, I can "remove" / delete related ASSERT , but I am not sure that it is "good solution"

P.P.S.

at first I replace "all" to "headless" a-la this:

    - name: Build all the things
      run: |
        scripts/concierge.py full-upgrade --backend "${{ matrix.backend }}" -DM3CC_TARGET=I386_LINUX headless -m3gdb

2022-10-18: Possible fixed . . .

[demoitem]

The next step is.... I have merged zcxh into master and will push that tomorrow or next day. I think any further testing should be based on that. The trouble is the difficulty in diagnosing problems based on the set of variations. The emails I get don't specify the branch being built, the backend being used, the backend being targeted or the quake defs defined. We need a more systematic method of problem reporting. There was a mention of libunwind on windows in reference to zcxh. That may be so and having libunwind is necessary but not sufficient. I have added 5 new instructions to the M3 IR. start_try end_try invoke_direct invoke_indirect landing_pad only the GCC and llvm backend implement these instructions. Both these backend have mechanisms to inject the gcc_except_table tables into the code streams. It is hard to see how the c backend could accomplish this without calling c++. And it is even harder to imagine the integrated windows backend doing the same without a lot of work. The new zcxh implements the Itaniam abi as implemented by the C++ runtime with a couple of changes. We define a personality function but don't do anything with it since raise does all the work. Also we don't handle cleanups or certain other exception types which only apply to say C++. A major imperative was to ensure the current sjlj exception mechanism worked as a default. That said, the new exception mechanism should be mostly portable across most unixes. If it works with GCC then it should work with m3. Regards Peter On Tue, 11 Oct 2022 at 19:43, VictorMiasnikov ***@***.***> wrote:

…

That is a strange error. It's hard to see it being related to exception handling changes. … <#m_8332834844049596473_> On Tue, 11 Oct 2022 at 01:41, VictorMiasnikov *@*.*> wrote: Please, see some "1/2 binary" in https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag <https://github.com/VictorMiasnikov/cm3/releases/tag/d5.11.9-ZZYYXX-20220907_04-27_Tag> P.S. 2022-10-07: It has been tested on AMD64_NT. There is "all good". ( Of course, it is only "regression test" ) Sorry: may be, I see regression: https://github.com/VictorMiasnikov/cm3/actions/runs/3190726991/jobs/5206462414 <https://github.com/VictorMiasnikov/cm3/actions/runs/3190726991/jobs/5206462414> AMD64_NT / build failed 5 days ago in 12m 45s cd D:\a\cm3\cm3\m3-ui\ui D:\a\cm3\install\cm3\bin\cm3.exe -build -DBUILD_DIR=AMD64_NT -DROOT=D:\a\cm3\cm3 -DTARGET=AMD64_NT -DM3_BACKEND_MODE=C --- building in AMD64_NT --- ignoring ../src\m3overrides new source -> compiling Pixmap.i3 new source -> compiling TrestleComm.i3 ( . . .) new source -> compiling TextVBT.m3 *** *** runtime error: *** <ASSERT> failed: NOT is_const *** file "../src/values/Module.m3", line 1045 *** — Reply to this email directly, view it on GitHub <#1095 (reply in thread) <#1095 (reply in thread)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABALZX6WZFBVF3TAFKYEKN3WCQTKTANCNFSM6AAAAAAQ4EEQF4 <https://github.com/notifications/unsubscribe-auth/ABALZX6WZFBVF3TAFKYEKN3WCQTKTANCNFSM6AAAAAAQ4EEQF4> . You are receiving this because you authored the thread.Message ID: @.*> Now I think: "What is next step"? — Reply to this email directly, view it on GitHub <#1095 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABALZXY2FESYRJG74KRUQZ3WCUSCNANCNFSM6AAAAAAQ4EEQF4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[VictorMiasnikov]

} (. . .) sjlj exception mechanism

AMD64_NT use SEH

} (. . .) llvm backend

We have LLVM backend on AMD64_NT and i386_NT
( I even can compile Hello.exe)

} only the GCC and ( . . .) backend implement these instructions.

"GCC backend of i386_NT" is possible. I have ( and it's published) .exe and others binary.

But it works strange -( There are need more investigations