Skip to content
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

Provide C interface #13

Closed
zokier opened this issue Apr 3, 2018 · 7 comments · Fixed by #14
Closed

Provide C interface #13

zokier opened this issue Apr 3, 2018 · 7 comments · Fixed by #14

Comments

@zokier
Copy link
Contributor

zokier commented Apr 3, 2018

Bloaty has a use for Rust name demangling (see bloaty#110). Bloaty being C++ application we'd need to have a C interface to be able use rustc-demangle for that purpose.

I made quick wrapper (zokier/rustc-demangle-clib) but I think it is something that would make sense to have in-tree here.

The exact form of the interface can be discussed further, that wrapper has been made solely for the needs of bloaty.

If agreed, I can polish the the code (add tests and docs) and submit it as PR here.

@zokier
Copy link
Contributor Author

zokier commented Apr 3, 2018

For further context, bloaty is a elf/mach file size analyzer, which I think would be useful for the wider Rust community if it were able to demangle Rust symbols.

@alexcrichton
Copy link
Member

I'd be totally down for supporting this! I think this library would make a great candidate for a C interface :)

If you want to send a PR I'd be more than willing to help take a look and see how we can land it

@zokier
Copy link
Contributor Author

zokier commented Apr 4, 2018

I hit bit of a snag while implementing this in the same package; rustc-demangle is no_std (which is nice), but crate-types cdylib/staticlib require eh_personality/panic_fmt implementations. While I could add dummy implementations, that would not be appropriate for lib/rlib crate types.

Not sure if this could be resolved with some conditional compilation or feature flag trickery, rust-lang/rust#20267 is bit ambiguous.

Overall this leads me to think that it might be better to have the C library part in its separate crate/package. Is there some general best practice on how this sort of thing is organized? Can the C lib still live in this same source tree as some sort of sub-crate(??) that Cargo then builds separately?

Anyways, my WIP branch is at https://github.com/zokier/rustc-demangle/tree/c_library if you want to take a look. The wrapper function code itself is ready, but I am not able to build a cdylib/staticlib from it.

@alexcrichton
Copy link
Member

Aha yes indeed! I was thinking though that the C API would be a separate crate that just links to rustc-demangle, which I think would fix the need for std and lang items?

@alexcrichton
Copy link
Member

A good example to go off I think is perhaps the regex-capi crate -- https://github.com/rust-lang/regex/tree/master/regex-capi

@zokier zokier mentioned this issue Apr 8, 2018
@michaelwoerister
Copy link
Member

michaelwoerister commented Dec 9, 2019

@zokier & @alexcrichton Is there anything blocking this PR? What would be needed to push it over the finish line?

EDIT: I meant to post this on #14.

@alexcrichton
Copy link
Member

Nah nothing blocking, just never got around to finishing it I think!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants