Loading...

​​ffi-unwind design meeting

​​Links

• ​​Blog post

• ​​hackmd notes from March 2 meeting

• ​​Older meeting notes (note that Proposal numbers) don’t line up

• ​​​+ffi-unwind 2020-01-13​ 

​​Three proposals

• ​​One

• ​​Two

• ​​Three

​​Notes and minutes

• ​​The biggest question before us is:

• ​​do we want a “C unwind” ABI or not

• ​​With Proposal Two:

• ​​extern “C” means “no unwind”, if you try to unwind you get UB

• ​​exception: “forced unwind”, so long as there are no dtors

• ​​extern “C unwind” means 

• ​​if you invoke with -Cpanic=abort​, we’ll catch the exception and abort

• ​​Proposal 3

• ​​no “C unwind”

• ​​just have “extern C” but unwinding is allowed when -Cpanic=unwind​ and otherwise not

• ​​exception: “forced unwind”, so long as there are no dtors

• ​​basically the same as C code calling C++ that may throw an exception

• ​​Size measurements?

• ​​No because these proposals all basically allow us to avoid overhead, 

• ​​Note that in proposal 3: 

• ​​extern “C” with panic=unwind can unwind, and hence there might be some landing pads that are not optimized away

• ​​relatively minor case

• ​​but users who are size-sensitive are often using panic=abort anyway and this doesn’t apply then

• ​​If we added a “no-unwind attribute” to functions, then:

• ​​we could get some size wins (but wouldn’t apply to ptr calls unless we propagate to type system)

• ​​you would also get the reasoning benefits

• ​​From previous meeting, came to conclusion that

• ​​A “C unwind” ABI is “better” than a unified “C” ABI if the annotations are all correct:

• ​​
  

• ​​A single “C” ABI is better in the following ways:

• ​​Less error prone, 

• ​​If the user invokes a function that has “C” ABI but actually unwinds:

• ​​Given a “C unwind” ABI, that is UB

• ​​Given a unified ABI, it unwinds successfully

• ​​Some cases where this could happen somewhat unexpectedly:

• ​​C++ could throw bad-alloc exceptions

• ​​Ralf raised some soundness concerns around catch_unwind​:

• ​​code may rely on catch_unwind​ to catch exceptions, do some “fixup”, and then re-throw the exception

• ​​currently, catch_unwind​ lets foreign exceptions unwind through

• ​​but this is relatively easy to fix

• ​​ultimately an orthogonal concern

• ​​If we adopt a unified ABI:

• ​​the main downside is that you can have libraries that “rely” on C++ exceptions

• ​​those libraries work in -Cpanic=unwind