You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for generating bindings with the C-unwind ABI #2224
Feature request for generating bindings with the C-unwind ABI for generated functions and function pointers. I'd love for this to be supported both via the bindgen Rust API and CLI.
rust-lang/rust#101263 was just merged so as of the next nightly, structs with C-unwind fn pointers will be able to implement Debug. I believe this is unblocked.
A function MUST be marked extern "C-unwind" if it uses the C ABI (e.g. because it is linked by name e.g. between Rust and C/C++) and an unwind can ever cross it (e.g. a Rust panic or C++ exception). A function SHOULD be marked extern "C" if it is known that it will never be unwound over. A function MUST be extern "C" to be callable from standard C. (Most platforms offer a way to compile "unwind compatible" C, however, as well as of course extern "system".)
As far as I'm aware, on all current platforms which support extern "C-unwind", the only difference in ABI between "C" and "C-unwind" is out-of-band (i.e. using "C-unwind" where "C" is expected will cause no issues). However, an ABI where this is not the case is simple to imagine (e.g. a reserved exception pointer register rather than out-of-band unwinding).
My understanding is the decision to mark a function as C ABI or C-unwind ABI depends on whether the code is compiled with -fexceptions or C++ exceptions enabled.
This is an out of band configuration that is passed to the C/C++ compiler, so I'd expect a configuration option for bindgen to alter its behavior.
Activity
CAD97 commentedon Jun 28, 2022
extern "system"is also useful.lopopolo commentedon Oct 22, 2022
rust-lang/rust#101263 was just merged so as of the next nightly, structs with C-unwind fn pointers will be able to implement
Debug. I believe this is unblocked.pvdrz commentedon Oct 24, 2022
@lopopolo @CAD97. When would a function be tagged as
extern "C-unwind"instead ofextern "C"systematically?CAD97 commentedon Oct 24, 2022
A function MUST be marked
extern "C-unwind"if it uses the C ABI (e.g. because it is linked by name e.g. between Rust and C/C++) and an unwind can ever cross it (e.g. a Rust panic or C++ exception). A function SHOULD be markedextern "C"if it is known that it will never be unwound over. A function MUST beextern "C"to be callable from standard C. (Most platforms offer a way to compile "unwind compatible" C, however, as well as of courseextern "system".)As far as I'm aware, on all current platforms which support
extern "C-unwind", the only difference in ABI between"C"and"C-unwind"is out-of-band (i.e. using"C-unwind"where"C"is expected will cause no issues). However, an ABI where this is not the case is simple to imagine (e.g. a reserved exception pointer register rather than out-of-band unwinding).pvdrz commentedon Oct 24, 2022
ok my question is a bit less broad than that. How can bindgen determine from the headers if a function is
CorC-unwind?lopopolo commentedon Oct 24, 2022
My understanding is the decision to mark a function as C ABI or C-unwind ABI depends on whether the code is compiled with
-fexceptionsor C++ exceptions enabled.This is an out of band configuration that is passed to the C/C++ compiler, so I'd expect a configuration option for bindgen to alter its behavior.
schell commentedon Nov 15, 2024
It would also be nice to be able to specify an ABI override for function pointers stored in structs. Is that on the roadmap?
pvdrz commentedon Nov 15, 2024
There is no roadmap here 🤣 . Jokes aside, if you can create an issue asking for this feature we can discuss its feasibility there