658443 - Stack unwind metadata not generated on platforms where ABI requires it

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Baseline JIT (CodegenLIR), defect)

Description

[William Maddox]

Nanojit LIR_call generally conforms to the C/C++ ABI on the host/target platform, and we expect to be able to call statically-compiled native functions in the host process directly from JIT-generated code.  Our current observance of ABI requirements, however, appears to be limited to register usage conventions stack frame setup/teardown.  Some platform facilties, however, such as table-based ("zero cost") exception handling and crash diagnostics, may need to walk the stack frame-by-frame, requiring metadata to permit stack adjustments to be undone and volatile registers to be restored as the stack is unwound.  Nanojit does not generate such metadata, which is required under 64-bit Windows, and possibly on some other platforms.

In some cases, the host may prohibit native exceptions.  For example, in Tamarin, we have our own setjmp/logjmp-style exception handling machinery upon which the implementation of AS3 exceptions is based.  This mechanism does not interoperate cleanly with native unwinding mechanisms, particularly with respect to peforming C++ destructors upon an abnormal exit from the scope of
a stack-allocated object. Thus, we expect that C/C++ functions called from JIT-ed code will not throw native exceptions, and it should never be the case that the native exception handling mechanism will need to walk a frame belonging to a JIT-ed function.

While I can imagine use cases in which strict adherence to the C/C++ ABI in all respects might be desired, allowing first-class interoperability with C/C++ in every respect (e.g., native exceptions), this is probably not of much concern to the current users.  On the other hand, it is quite useful for crash dumps, profilers, and debuggers to correctly step over JIT-generated frames so that both the (native) callers and callees of such code can be correctly handled.

Issues:

1) 64-bit Windows provides an API for making the unwind metadata available to the system when generating code dynamically.  It is unclear what facilities of this sort exist on other platforms, and what degree of commonality they may exhibit.

2) The basic register usage conventions are widely respected across all platforms based on a particular CPU architecture, but exception handling on 64-bit Windows and G++/x86_64 is different (and likewise for 32-bit Windows and G++/i386), though all of the table-based implementations were likely inspired by the IA64 ABI promulgated by Intel.

3) Full compliance with the 64-bit Windows ABI places some restrictions on the shape of the function prologue and epilogue in addition to the metadata, as well as restrictions on where RSP can be modified.  On a first examination, I don't think they are particularly onerous, but conforming to them, as well as generating and registering the metadata is an additional burden.

4) Since we neither expect to throw nor catch native exceptions in JIT-generated code (as there are no LIR instructions to do this), we do not need any exception-specific (EH) metadata.  In the worst case, we simply need to be able to reliably unwind *through* a JIT-generated frame.  If we are careful to save any volatile registers prior to calling into JIT-generated code, the metadata for that code can lie freely about its register usage, such as volatile register save/restores.  All that is really needed is sufficient information to pop the stack frame and locate the return address, i.e., the PC for the previous frame.  This would minimize the effect on the code generator itself, though dealing with platform-specific APIs to register the metadata would remain annoying.

Comment 1

[Sylvestre Ledru [:Sylvestre]]

Tamarin is a dead project now. Mass WONTFIX.

Comment 2

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.