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

Allow overriding lang-items from different crates #7901

Closed
huonw opened this issue Jul 19, 2013 · 4 comments
Closed

Allow overriding lang-items from different crates #7901

huonw opened this issue Jul 19, 2013 · 4 comments

Comments

@huonw
Copy link
Member

huonw commented Jul 19, 2013

Building on the new optional lang items, this would, for example, allow someone to substitute a new version of malloc (e.g. because they want to count the number of allocations, or have a specialised, high-performance implementation).

Only allowing it cross crate would mean there wouldn't be any confusion about which takes precedence in:

mod foo { #[lang="exchange_malloc"] fn foo_malloc() { } }
mod bar { #[lang="exchange_malloc"] fn bar_malloc() { } }

This possibly couldn't work at all, because the other crates have had the original lang-item compiled into the appropriate places.

@alexcrichton
Copy link
Member

I think that this would be fairly difficult to do, and the semantics should definitely be fleshed out before any work is done.

When translating, if there's a spot which uses the exchange_malloc lang item, then LLVM has to emit some call to something at that point. I think that this means that normal name-mangling couldn't happen for lang items because otherwise you're emitting a call to something you can't override.

One possible route to take that has other benefits would be to canonicalize all lang_item names to the same value. Something like __lang_item_<name of lang item>. I'm not quite sure how things like tcmalloc/jemalloc work by dynamically loading them at runtime and everything uses them, but this could probably work along the same lines (everyone assumes the memory allocation function is called malloc). Another benefit of this would be that a library crate could be compiled with a dependence on lang items, but not actually define them itself.

So we could create a libcore which is libstd - librustrt or something like that, but it could still have methods for things like ~str and ~[T] without defining the lang_item for allocation. Whenever you linked against it, you would be required to define the symbol, but at compile-time for the crate it wouldn't matter. Not only would this be hugely beneficial for allocation functions, but it'd be fantastic if libcore could still use fail!(). Programs linking against libcore (like kernels) would have to define what exactly they want to happen whenever a fail!() occurs (or an out-of-bounds exception)

Basically

  • I'm not sure if this is possible without canonicalizing the names of lang_items (functions make sense, do traits?)
  • If we do that, we could extend this to make missing lang_items even more flexible!

I'm curious how feasible this is. What do others think?

@thestinger
Copy link
Contributor

You can't rely on the same trick used by tcmalloc and jemalloc because it implies dynamic linking. It only works if the application dynamically links against the standard C library and it uses weak symbols. The real solution for the allocator is to use the je_ prefix and extend LLVM's detection of malloc and free to them.

@huonw
Copy link
Member Author

huonw commented Nov 15, 2013

Triage: I don't know of any progress.

@thestinger
Copy link
Contributor

I don't think it makes sense to override these. Thanks to inter-procedural optimization, you cannot replace functions defined in a compiled binary with alternate functions. It's possible to override weak symbols defined in a dynamic library like malloc and free, and I think that's enough. Since we aren't using jemalloc anymore there's nothing preventing the usual weak symbol override.

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 4, 2021
…p1995

Prevent clippy::needless_lifetimes false positive in async function definition

Scan `OpaqueDef` bounds for lifetimes as well. Those `OpaqueDef` instances are generated while desugaring an `async` function definition.

This fixes rust-lang#7893

changelog: Prevent [`clippy::needless_lifetimes`] false positive in `async` function definition
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

No branches or pull requests

3 participants