fix regression in panic_misaligned_pointer_dereference

[thomasdangl]

#118362 introduced a regression that breaks pointer dereferencing in core.

use std::ptr;

pub fn main() {
    let a: *const u8 = ptr::null();
    dbg!(unsafe { *a });
}

[profile.dev]
panic = "abort"

[build]
target = "x86_64-pc-windows-msvc"

[unstable]
build-std = ["std", "panic_abort"]
build-std-features = ["panic_immediate_abort"]

[target.x86_64-pc-windows-msvc]
linker = "rust-lld.exe"

Until 8de5bd0 this worked totally fine.
However, since the commit ended up in master, the linker is quite unhappy about the symbol:

  = note: rust-lld: error: undefined symbol: core::panicking::panic_misaligned_pointer_dereference::h89d210946737113d
          >>> referenced by C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\fs.rs:517
          >>>               libstd-93222e7335411a9e.rlib(std-93222e7335411a9e.std.f1f999d9f794207e-cgu.06.rcgu.o):(std::sys::windows::fs::File::readlink::ha67e29df7ba249d0)
          >>> referenced by C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\fs.rs:518
          >>>               libstd-93222e7335411a9e.rlib(std-93222e7335411a9e.std.f1f999d9f794207e-cgu.06.rcgu.o):(std::sys::windows::fs::File::readlink::ha67e29df7ba249d0)
          >>> referenced by C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\fs.rs:519
          >>>               libstd-93222e7335411a9e.rlib(std-93222e7335411a9e.std.f1f999d9f794207e-cgu.06.rcgu.o):(std::sys::windows::fs::File::readlink::ha67e29df7ba249d0)
          >>> referenced 33 more times

Is there a specific reason panic_misaligned_pointer_dereference is supposed to be inlined?
Otherwise I suggest we just avoid inlining it for panic_immediate_abort.

Perhaps this is also something to be added as an example for #118393.

Best,
Thomas

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[saethlin]

Is there a specific reason panic_misaligned_pointer_dereference is supposed to be inlined?

Yes, the entire point of that feature is to permit these symbols to be fully optimized out, along with all the formatting code that they drag in.

Can you explain your use-case more? I don't understand how the feature used to work for you before; you're building an unoptimized standard library so it should be full of panic formatting code.

[thomasdangl]

Yes, the entire point of that feature is to permit these symbols to be fully optimized out, along with all the formatting code that they drag in.

I see. In that case it might make sense to investigate further within the compiler.
Something is generating references to non-existing symbols.

Can you explain your use-case more? I don't understand how the feature used to work for you before; you're building an unoptimized standard library so it should be full of panic formatting code.

I'm building a no_std application with panic=abort for Windows. My goal is to reduce the overall code size of my program using panic_immediate_abort among other options.
I'm not worried about having the formatting code in the debug build (although optimizing this away would be desirable as you have mentioned).

Rather, my problem is that neither my program nor std is building anymore because the offending line causes an linker error whenever a pointer is dereferenced (with panic_immediate_abort). So in that sense, the problem is independent from any specific use case.

[saethlin]

I can trivially reproduce all the behavior you're experiencing on Linux with the default linker. That's good, I suppose.

Since I wrote the alignment checks and I've fiddled a lot with panic_immediate_abort, I'll assign myself to this.

r? saethlin

[saethlin]

@thomasdangl The PR that I linked this to is now part of the latest nightly. Can you confirm that the latest nightly works for you?

[Vollbrecht]

we were also effected by this in https://github.com/esp-rs/esp-idf-hal but our CI is working again with latest nightly.