HardFault in ch9 is out of date

[malachid]

On https://docs.rust-embedded.org/discovery-mb2/09-registers/bad-address.html
it states:

(gdb) list
1040  #[allow(unused_variables)]
1041	#[doc(hidden)]
1042	#[cfg_attr(cortex_m, link_section = ".HardFault.default")]
1043	#[no_mangle]
1044	pub unsafe extern "C" fn HardFault_(ef: &ExceptionFrame) -> ! {
1045	    #[allow(clippy::empty_loop)]
1046	    loop {}
1047	}
1048	
1049	#[doc(hidden)]
1050	#[no_mangle]

When hitting this break point, the signature is:

pub unsafe extern "C" fn HardFault_() -> ! {...}

The rest of the page assumes that the ef ExceptionFrame parameter is there to inspect.
This results in output like:

No symbol 'ef' in current context

This is with rustc 1.93.0 on Ubuntu 24.04.4 LTS.

[BartMassey]

Easily reproduced. Looks like stack handling has changed somehow? I've looked at the source code for cortex_m_rt pretty carefully, but can't quite see why this is failing.

Anyone?

[vittorius]

I've also come across this, it seems that cortex_m_rt's default hard fault handler is now parameterless, there's no ef: ExceptionFrame parameter in it anymore. I had to define my own:

#[exception]
#[allow(unused_variables)]
unsafe fn HardFault(ef: &ExceptionFrame) -> ! {
    loop {}
}

Maybe let's augment this chapter with instructions to add our own hard fault handler with the correct signature?

[BartMassey]

Would love to see a PR. Would also like to understand why cortex-m-rt changed this signature. Thanks much for the update!

[vittorius]

Added a PR for the fix: #103

[BartMassey]

I'm still very confused. How can the default HardFault handler declare itself not to accept a parameter, but then be invoked with one. I mean, I get that that could work, but it seems like an accident and quite error-prone. I guess if you hit the default HardFault handler, it doesn't really matter how messed up things get, probably, but…

Thanks for looking into this. Really want to sort out what's going on before I take a PR. Maybe ask on the REWG Matrix?

[vittorius]

Asked in the Rust Embedded Matrix chat https://matrix.to/#/!BHcierreUuwCMxVqOf:matrix.org/$l2JHPELVFm7xnVh0T7_flGYAMrMygzcpM5vMMm1a4_g?via=beeper.com&via=catircservices.org&via=matrix.org

[adamgreig]

The default cortex-m-rt HardFault stopped having an ExceptionFrame parameter in rust-embedded/cortex-m#476 which meant we didn't need to emit the trampoline by default, saving flash and making hardfaults more user-configurable (some users don't want our trampline included).

The documentation for the exception macro explains a bit: https://docs.rs/cortex-m-rt/latest/cortex_m_rt/attr.exception.html#hardfault-handler

Essentially, it used to be the case that the default HardFault you got if you didn't specify your own had an unused ExceptionFrame parameter (and the blob of assembly required to generate it), but now the default doesn't, and if you want it, you have to define your own HardFault using the macro... which defaults to then including the trampoline to preserve the old behaviour, but can have it disabled with trampoline=false.

At the time this didn't seem like a breaking change because the ExceptionFrame was entirely unused by cortex-m-rt and so invisible to users... unless, as in this book, they use the debugger to dig into cortex-m-rt's internals and see it. I think probably the best bet is to add a user-defined HardFault handler in the book example code, but I appreciate it's a bit annoying.