Carlo Kok (Jan 05 2022 at 07:23): Carlo Kok (Jan 05 2022 at 07:23):Is there an up to date document with the current features of cranelift? Like how can I find which targets are currently supported, which cpus, if seh (win32, win64, and landingpads on posix), arm etc are all working?
bjorn3 (Jan 05 2022 at 10:24):I don't think there is. For architectures x86_64, AArch64 and s390x are supported. For unwinding info dwarf and seh are supported. For calling conventions on x86_64 windows fastcall and systemv are supported. On aarch64 the apple and I believe aapc (or whatever the default on most unixes is on aarch64) are supported. For supported OSes it is the responsibility of the user of cranelift to handle this. cranelift-codegen doesn't care beyond the calling comvention. cranelift-object supports emitting elf, macho and coff object files.
Carlo Kok (Jan 05 2022 at 11:57):So no arm(32 bits) and i386. and unwinding only, no catching?
Carlo Kok (Jan 05 2022 at 11:57):(either way, cool)
bjorn3 (Jan 05 2022 at 11:59):Correct. There is an issue for adding 32bit x86 support and an issue for adding landingpad support for exceptions (i need the latter for cg_clif to implement panics).
Carlo Kok (Jan 12 2022 at 13:29):I was reading through the EH proposal but has any decision been made on the approach yet?
Carlo Kok (Jan 12 2022 at 13:59):(both IR and "output")
Chris Fallin (Jan 12 2022 at 17:06):there was some discussion in a meeting a few months back (this one: https://github.com/bytecodealliance/wasmtime/blob/main/meetings/wasmtime/2021/wasmtime-10-28.md)
Chris Fallin (Jan 12 2022 at 17:06):the outcome of that is that I think we want to build out DWARF-style unwinding and use that
Chris Fallin (Jan 12 2022 at 17:07):IR will probably look something like LLVM's landingpads, but there are undoubtedly a lot of details still to specify
Carlo Kok (Jan 14 2022 at 12:11):That sounds perfect and would probably allow for both Win32/64 SEH and posix landingpads.
Amanieu (Jan 14 2022 at 12:55):SEH uses funclets which need to be represented in a fundamentally different way in the IR. However what could be done is emulating DWARF on top of SEH like GCC does for x86_64-windows.
Carlo Kok (Jan 14 2022 at 13:33):To be able to catch any win32 exception (like so, overflows etc) seh exceptions have to be catchable though. I do think it should be possible to allow an ir level format that can capture both.
bjorn3 (Jan 14 2022 at 13:36):Only exceptions from wasm code (in case of wasmtime) and C++ exceptions (in case of cg_clif) are necessary to be catchable. The rest is just a nice to have I think.
Amanieu (Jan 14 2022 at 14:30):DWARF-style unwinding is easy to model in an IR because it's just about making a function call return to more than one place depending on whether it unwinds. On the other hand SEH requires invokes landing pads as their own function, with a pointer to the stack frame of the original function so that any needed locals can be accessed. This is much harder to model in the IR.
Carlo Kok (Jan 17 2022 at 08:46):Would it be wild to suggest to model exceptions with funclets that get "inlined" when emitting landingpads then?
Amanieu (Jan 17 2022 at 13:09):I would recommend reading this document which explains why LLVM has 2 separate IR constructions to represent exception handling.
Carlo Kok (Jan 17 2022 at 20:18):I have actually; I've also used llvm. The landingpad logic in llvm predates the SEH code by quite some time. I do think it should be possible to combine them. The only "real" usecase I can think of is to represent try/catch/finally for both after all.
Chris Fallin (Jan 18 2022 at 03:25):@Carlo Kok such a thing strikes me as somewhat more complex than we need; an abstraction with subtle semantics (activation frame within an activation frame) that we then "undo" via a particular transform. But possibly I'm missing some important reason why this SEH-specific behavior needs to be accessible from CLIF
Carlo Kok (Jan 18 2022 at 07:24):I see your point now that that might be a bit trickier than I thought. The reason I'm bringing it up is that to emit a try/catch, you have to take vastly different paths depending on if you are on Windows or something else. Even though you really only use this construct to emit a try/catch. So I guess from my pov it's a where do you put the complexity; in the compilers that call Cranelift or in cranelift.
Last updated: Dec 23 2024 at 13:07 UTC