[llvm-bugs] [Bug 46396] New: WebAssembly exception handling catchpads cannot be addressed sometimes

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46396

            Bug ID: 46396
           Summary: WebAssembly exception handling catchpads cannot be
                    addressed sometimes
           Product: libraries
           Version: trunk
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: sascha.braun.lpz at googlemail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 23634
  --> https://bugs.llvm.org/attachment.cgi?id=23634&action=edit
code sample (cpp)

-- I think this shall be forwarded to Heejin Ahn. --

Hi,

I'm in the process of implementing several WebAssembly VMs, including EH,
working with what is so far already present in LLVM.

I think there is a bug in how codegen is done when catchpads are nested. The EH
table I think is fine.

Please see attached cpp sample. 

Function test23any_nest1_llvm: I think it is impossible to execute the code in
the inner catch for both test3class and test5class. One catchpad can be
executed if my _Unwind_CallPersonality() writes it's according EH table entry
back to memory address 0.

Function test23any_nest1: Here it is ok. Inner CPs for both types can be
exec'd, I think it is because catches for both types are also present in the
outer try/catch.

My assumption is it is related to how child catchpads are deleted in
'wasmehlateprepare'.

You can contact me directly sascha.braun.lpz at googlemail.com. If I am wrong I
would be grateful if you could point out what value _Unwind_CallPersonality
shall write to memory addr 0 to select the catch for test3class or test5class.

Many Thanks
Sascha

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200619/610099e0/attachment.html>