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

Clarify docs around what libcore users must declare #57255

Open
JustAPerson opened this issue Jan 2, 2019 · 1 comment
Open

Clarify docs around what libcore users must declare #57255

JustAPerson opened this issue Jan 2, 2019 · 1 comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@JustAPerson
Copy link
Contributor

JustAPerson commented Jan 2, 2019

I find the documentation about what libcore depends on a bit confusing right now. I'm trying to make my #[no_std] crate compile after a year on inactivity for context.

Now firstly, this section describes several symbols, but is the actual symbol name relevant (ignoring memcpy/memset/etc)? Or do we only care about the existence of some function labeled with the appropriate attribute? The distinction between symbol name and the associated lang attribute is confusing here.

rust_begin_panic - This function takes four arguments, a fmt::Arguments, a &'static str, and two u32's. These four arguments dictate the panic message, the file at which panic was invoked, and the line and column inside the file. It is up to consumers of this core library to define this panic function; it is only required to never return. This requires a lang attribute named panic_impl.

It appears that the #[lang="panic_impl"] mentioned is already declared in libcore/panicking.rs. It appears that this should refer to #[lang = "panic_fmt"] instead, which is what libcore users formerly had to declare but is now implicitly declared by by the new #[panic_handler]. Rustc will complain about missing a #[panic_handler] currently. So this section should probably be updated to refer to #[panic_handler] instead.

rust_eh_personality - is used by the failure mechanisms of the compiler. This is often mapped to GCC's personality function, but crates which do not trigger a panic can be assured that this function is never called. The lang attribute is called eh_personality.

It should probably be mentioned that #[lang="eh_personality"] seems only necessary if panic=unwind. Additionally should perhaps mention _Unwind_Resume as well (which theoretically is only necessary for panic=unwind builds but can erroneously be required for panic=abort opt-level=0 builds see #53301). There's actually more of these eh functions that should be perhaps mentioned depending on your target. The subtleties are explained in libpanic_unwind and libpanic_abort.

Along the same lines, the docs of liballoc should probably also mention #[alloc_error_handler] (see #51540).

I can try writing up a draft or PR but wanted to get feedback first.

@frewsxcv frewsxcv added the A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools label Jan 2, 2019
@steveklabnik
Copy link
Member

Yes, this doc is out of date; we've now stabilized panic handling stuff, so this is what you need today https://github.com/intermezzOS/kernel/blob/master/src/panic.rs

@jonas-schievink jonas-schievink added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-enhancement Category: An issue proposing an enhancement or a PR with one. labels Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-docs Area: Documentation for any part of the project, including the compiler, standard library, and tools C-enhancement Category: An issue proposing an enhancement or a PR with one. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants