panic_immediate_abort and no_std

[nazar-pc]

I was looking for a way to detect whether panic handler needs to be defined or not in no_std crate (which can be compiled on its own for a custom target or used as a dependency), but didn't find a way to do that with conditional compilation.

I did find panic_immediate_abort feature though. Now I'm wondering if it would make sense to define a placeholder panic handler in core when this feature is used, since it is clear what it should look like: abort immediately. There should be no need to require developer to define it explicitly in this case.

[adamgemmell]

Any no_std project must define a panic handler. In my opinion this should generally be defined in the binary crate and a library shouldn't do so, or at least provide a feature to disable doing so.

panic_immediate_abort is a feature that already links in a panic handler that immediately aborts. However, this panic handler, panic_abort depends on alloc due to Android (it allocs a string to return a message I think). It's usage requires that panic_abort is built and available, and I think panic_abort only gets linked in if you build std.

Say you built a simpler panic_abort and put it in core by default unless a flag is passed - then to define their own panic strategy the user must rebuild core which I'm not sure is acceptable. I don't think there's a way around that unless #[linkage="weak"] could be reliable for all targets.

[nazar-pc]

I was specifically writing about custom target where you have no choice other than to build core anyway, so it is not just "acceptable", it is a requirement.

I have no idea what panic_immediate_abort has to do with alloc though.

[adamgemmell]

Looking at things from the perspective of core, it must support many different targets and custom targets are at the bottom of that list unfortunately. I'm not sure how this idea would look without impacting the majority of users who don't need to use build-std.

[nazar-pc]

I am specifically talking about cases where core will be built and only if panic_immediate_abort is also specified. Unless those two conditions are met, there is no change.

[adamgemmell]

panic_immediate_abort's purpose is to link in a panic handler so it would have to be a different feature name. Could you be more specific about your idea?

[nazar-pc]

But I do want to have a global panic handler that just aborts, which seems to match panic_immediate_abort pretty well.

I have a custom target that for x86-64 looks like this: https://github.com/nazar-pc/abundance/blob/f1b4aba909fa65e5bf6111284b9a743c3e42def7/crates/contracts/x86_64-unknown-none-abundance.json
Eventually it'll be RISC-V based and code will run in a VM, I'm using x86-64 for now to test things.

Other developers are expected to use this target to build shared libraries with it. The objective is to make it feel as "normal Rust" as possible. The fact that it compiles and runs tests natively, but requires to define a panic handler when compiled for this target is a friction point.
So I'm looking for ways to reduce that friction.

Ideally, if my target already specifies "panic-strategy": "abort" and already builds core because it is a custom target, I'd expect for compiler to provide a default panic handler unless overridden (just like it is done with std). Or at very least reduce the complexity to a single CLI feature flag rather than requiring custom target-specific boilerplate in the code that other developers write.

Right now the build command is fairly verbose and looks something like this (+panic handler boilerplate required):

cargo rustc -Z build-std=core --crate-type cdylib --target x86_64-unknown-none-abundance.json

Together with #95 and some way to customize the default crate type, I hope to eventually get to this instead (and no panic handler boilerplate required):

cargo build --target x86_64-unknown-none-abundance.json

With custom build profile and other things the actual build line is even larger, so reducing things will hopefully allow to avoid writing custom cargo wrapper that abstracts this complexity.

[adamgemmell]

But I do want to have a global panic handler that just aborts, which seems to match panic_immediate_abort pretty well.

Yes, but panic_abort depends on alloc right now (for reasons that don't concern your target) - presumably you don't want to force your users to build alloc too.

I do not fully understand your project, but it looks like you might have a common library that users will bring into their projects and you also know a lot about the platform their projects will be running on? If so I think it would be ok to define a panic handler in your library (the reason I recommended against this before is that generally libraries may run on a variety of machines, but when a library knows the environment it can be ok - some libraries that specific to certain embedded chips do define a panic handler for example).

Generally speaking I think what you're suggesting could be useful (it's certainly true that many no_std projects will define a very simple panic handler) but it's more of a libs team concern than something to do directly with build-std. I suggest raising an issue in the Rust repo or otherwise asking them directly.