-
Notifications
You must be signed in to change notification settings - Fork 702
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate extern wrappers for inlined functions #2335
Generate extern wrappers for inlined functions #2335
Conversation
c4fb085
to
039d7d0
Compare
039d7d0
to
aab6160
Compare
☔ The latest upstream changes (presumably ed3aa90) made this pull request unmergeable. Please resolve the merge conflicts. |
aab6160
to
65ff041
Compare
☔ The latest upstream changes (presumably 046d6f9) made this pull request unmergeable. Please resolve the merge conflicts. |
65ff041
to
9b7ccf5
Compare
☔ The latest upstream changes (presumably 95fd17b) made this pull request unmergeable. Please resolve the merge conflicts. |
9b7ccf5
to
0736ef4
Compare
☔ The latest upstream changes (presumably c17c292) made this pull request unmergeable. Please resolve the merge conflicts. |
0736ef4
to
e9abb71
Compare
☔ The latest upstream changes (presumably ed2d06e) made this pull request unmergeable. Please resolve the merge conflicts. |
e9abb71
to
4b5fec4
Compare
4b5fec4
to
d5d96e2
Compare
Question: Is it possible this same strategy can be extended to support (some) macros? |
what do you mean by this? Like to process function-like macros in a certain way? |
Yeah, for a macro that's function-like (e.g., https://github.com/openssl/openssl/blob/163b2bcd8b2e5cd149dfc8dce1ca096805559379/include/openssl/err.h#L198) automatically generate a C function that calls it and can be linked. I guess the user of bindgen would need to provide a signature. Or maybe we should just send PRs uptream to convert things to use |
we might be able to reuse some parts of this for that (or at least some things in a conceptual sense). We can continue this discussion over here: #753 |
If bindgen finds an inlined function and the `--generate-extern-functions` options is enabled, then: - It will generate two new source and header files with external functions that wrap the inlined functions. - Rerun `Bindings::generate` using the new header file to include these wrappers in the generated bindings. The following additional options were added: - `--extern-function-suffix=<suffix>`: Adds <suffix> to the name of each external wrapper function (`__extern` is used by default). - `--extern-functions-file-name=<name>`: Uses <name> as the file name for the header and source files (`extern` is used by default). - `--extern-function-directory=<dir>`: Creates the source and header files inside <dir> (`/tmp/bindgen` is used by default). The C code serialization is experimental and only supports a very limited set of C functions. Fixes rust-lang#1090.
test(static inlined): pretty print the diff Issue: rust-langGH-1090 test(static inlined): refactor paths once again - Because directory structure is confusing to the author of this commit rust-langGH-1090 test(static inlined): refactor test files - Expected files should be under tests/expectations/generated - Remove extern_stub.h because we can reuse the header from generate-extern-functions.h test(static inlined): diff test; generated files refactor(static inlined): integration test Issue: rust-langGH-1090 rust-langGH-1090: Integration tests integration test: document the GH issue integration test (macro): same order in impl as the trait for consistency integration test: move each setup into its own function, just to save face inline static func integration test resolve accidental conflict
4efcc6f
to
101cde0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So one thing that came up while looking at this... Is the second run even necessary? Can't we just have the suffix added needed on the first run, and rely on someone providing that symbol?
Might be overlooking something tho.
After playing with c constness I was able to achieve the following. If you pass this to bindgen: typedef int (*OPENSSL_sk_cmp_func)(const void **a, const void **b);
typedef int (*sk_void_cmp_func)(const void **, const void **);
static inline int sk_void_call_cmp_func(OPENSSL_sk_cmp_func cmp_func, const void *const *a,
const void *const *b) {
const void *a_ptr = (const void *)*a;
const void *b_ptr = (const void *)*b;
return ((sk_void_cmp_func)cmp_func)(&a_ptr, &b_ptr);
} it will emit this wrapper: int sk_void_call_cmp_func__extern(OPENSSL_sk_cmp_func cmp_func, const void *const *a, const void *const *b) asm("sk_void_call_cmp_func__extern");
int sk_void_call_cmp_func__extern(OPENSSL_sk_cmp_func cmp_func, const void *const *a, const void *const *b) { return sk_void_call_cmp_func(cmp_func, a, b); } |
Thanks, looks like that does resolve the
I think the fix is that for 0-argument functions, the |
It builds!!!! I have to wire everything up and make sure it works, but thank you so much for your efforts here. I'm super excited. |
I think the internet is mad at us and all the server request from github workflows are timing out 😅 I'm going to leave it like this for today and re-run CI tomorrow. |
…e naturally This PR uses the in-development bindgen support for static inline functions (rust-lang/rust-bindgen#2335) + an in-development boringssl patch (https://boringssl-review.googlesource.com/c/boringssl/+/56505) to allow using boringssl with rust-openssl without needing a .cargo/config override
Just wanted to confirm that everything is now working end-to-end. |
…e naturally This PR uses the in-development bindgen support for static inline functions (rust-lang/rust-bindgen#2335) + an in-development boringssl patch (https://boringssl-review.googlesource.com/c/boringssl/+/56505) to allow using boringssl with rust-openssl without needing a .cargo/config override
…e naturally This PR uses the in-development bindgen support for static inline functions (rust-lang/rust-bindgen#2335) + an in-development boringssl patch (https://boringssl-review.googlesource.com/c/boringssl/+/56505) to allow using boringssl with rust-openssl without needing a .cargo/config override
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From a skim it looks good, let's try this. r=me with the nits below, please squash the commits before landing as needed. Thanks for working on this, it took a while but it's great!
…e naturally This PR uses the in-development bindgen support for static inline functions (rust-lang/rust-bindgen#2335) + an in-development boringssl patch (https://boringssl-review.googlesource.com/c/boringssl/+/56505) to allow using boringssl with rust-openssl without needing a .cargo/config override
one thing I notice is that the headers don't get included in the generated C file. Is it intended ? |
see #2405 |
the issue is that as i'm building for the DS which has a pretty specific toolchain, i have to use the cc crate to build the C file |
I'm guessing that |
The include command of CC is to include a directory weirdly, but i found
out i could pass raw arguments to CC so i was able to force the include
this way
Le dim. 12 févr. 2023 à 17:48, Christian Poveda Ruiz <
***@***.***> a écrit :
… I'm guessing that .include("the_input_headers.h") should work
—
Reply to this email directly, view it on GitHub
<#2335 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AD4UF4OXVSTFOZEW4NVIXTTWXEH4XANCNFSM6AAAAAARXNQWCE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I'm not that familiar with |
If bindgen finds a
static
orstatic inline
function and the new--wrap-static-fns
option is enabled, then:c
source files with functions that wrap the non-external functions.link_name
of the bindings generated for non-external functions so they link against the wrappers instead.The following options were also added:
--wrap-static-fns-suffix=<suffix>
: Adds<suffix>
to the name of each wrapper function (__extern
is used by default).--wrap-static-fns-path=<path>
: writes the generatedc
code at<path>.c
or<path>.cpp
accordingly (/tmp/bindgen/extern
is used by default).Given that the C code serialization is experimental and only supports a very limited set of C functions, we also added a new
--experimental
flag and"experimental"
feature and all the three new options were put behind this feature.Fixes #1090.
If you're interested in how to use this feature see: #2405