Undesired link_name attributes generated

[waywardmonkeys]

Input C/C++ Header

int foo(void);

Bindgen Invocation

$ bindgen input.h

Actual Results

/* automatically generated by rust-bindgen */

extern "C" {
    #[link_name = "\u{1}_foo"]
    pub fn foo() -> ::std::os::raw::c_int;
}

I would like the output to not contain the link_name attribute as it shouldn't be necessary here.

I'm on macOS, so all symbols get the _ prefix ...

[emilio]

Right, so this is somewhat annoying, because fixing this would need to assume knowledge about the backend mangling on the target. The only reason those \u{1} are there is to avoid that...

Indeed we used to have a fair amount of bugs with C++ related to that.

So as much as this is only cosmetic, I don't think there's any particular reason to fix this, is there?

[emilio]

See all the need_mangling_hack mess that went away in f2b30c8, fwiw.

I think we could consider doing this as a best-effort thing, like: If we really know that the backend needs the extra underscore, just remove it, otherwise fall back to \u{1}, but again not sure it's worth the complexity.

[waywardmonkeys]

In my case, I typically build a bindings file once and commit it, rather than building it on the target machine. (This is the case for a lot of bindings...)

Also in my case, my bindings are for C APIs rather than C++ ... I understand the need for this for C++ APIs, but what is the need for C?

[emilio]

Sorry for the lag replying to this.

You can use the distrust_clang_mangling option to avoid generating any link_name at all, and C bindings should keep working.

If there's anything else we can do on our side (maybe renaming that option? We've done more breaking changes for the next release so it should be fine) please let me know, or submit a PR :)

[jethrogb]

I'm still getting the \u{1} even with trust_clang_mangling(false) (in combination with #1438)

    #[link_name = "\u{1}mbedtls_mpi_div_int"]
    pub fn mpi_div_int(Q: *mut mpi, R: *mut mpi, A: *const mpi, b: mpi_sint) -> raw_types::c_int;

[emilio]

It's expected that you get that if the symbol name is different from the name you're exposing. The trust-clang-mangling thing makes us avoid looking at the mangled name and assume it's the function name, but then you're changing that so we fix up the link name.

Do you need the link name to go away? If so, why? How would that link?

[jethrogb]

Right, link_name is definitely necessary. I expect it to be #[link_name = "mbedtls_mpi_div_int"] instead (the original symbol name before renaming it).

[emilio]

That wouldn't work on MacOS where we'd need an underscore. So the \u{1} is the right thing to generate.

[jethrogb]

I'm sorry, I don't quite understand. You're saying #[link_name = "\u{1}mbedtls_mpi_div_int"] is correct? That is obviously not what the symbol name is in my .a. I tried googling for “\u{1} link_name” but the top results are all random issues in this issue tracker 😃

[emilio]

Yes, that's right, see f2b30c8. Basically rustc passes link_name arguments as-is to LLVM, and LLVM adds per-backend mangling specially for C++ and such.

Prepending \u{1} is a hint to LLVM to avoid doing this (since we know actually the right mangling). It should end up being the right symbol name, though if you have evidence of the opposite let's file a new issue.

[awakecoding]

I ran into the same issue today with rust-mbedtls + pregenerating the bindings to be reused on Windows/macOS/Linux. As a temporary workaround, I did a search & replace in the generated bindings to remove the \u{1} prefix and it worked.