Use proper halting sequence for the panic handler

[dylanmckay]

Currently the current panic handler simply is loop { }. In release builds, this will likely optimize out and it also has problems because interrupts will still execute.

We should probably do something like this

asm!("cli"); // disable interrupts

loop {
    asm!( "" ::::: "volatile"); // wrong syntax, I'm going from memory
}

[dylanmckay]

This is a pretty big bug because if our panic handler halting loop gets optimized out, the panic handler will do nothing (and continue?)

[shepmaster]

our panic handler

libcore shouldn't have a panic handler at all — that's up to the application.

In certain cases, the panic handler may wish to try to write to a serial device to print the error, for example. Putting it in the core prevents that.

[shepmaster]

See also

libcore/src/panicking.rs

Lines 13 to 16 in 874fbe3

	//! The core library cannot define panicking, but it does *declare* panicking. This
	//! means that the functions inside of libcore are allowed to panic, but to be
	//! useful an upstream crate must define panicking for libcore to use. The current
	//! interface for panicking is:

[Rahix]

I have reenabled the panic handler (without formatting) on my fork: panicking.rs

This allows me to write a panic handler in my crate. The only issue is that somewhere an overhead of 193 bytes is generated. I guess this is code from formatting the panic arguments but I have not found the offending part of libcore yet.