Tracking issue for global-asm support (RFC 1548)

[nikomatsakis]

Tracking issue for global_asm! macro rust-lang/rfcs#1548:

Note that this is intended as a (particularly) experimental feature.

Feedback on its design is required, as well as comparisons with naked fns.

[jackpot51]

Don't take away naked functions!!!!!!!!!!!!!!!!!!!

They are a crucial component of building operating systems in Rust.

Without naked functions, it is impossible to do context switching without moving huge amounts of code into assembler. Converting such code to global_asm! is unnecessary, insecure, difficult to read and modify, and requires repeating code for each target.

[nikomatsakis]

@jackpot51 more detailed examples would be great :)

[nikomatsakis]

@jackpot51 but rest easy, I don't think we're in any hurry to make firm decisions here. :)

[ticki]

@nikomatsakis They're used in anything from interrupt handler to context switches. I would cry for 10 years straight if you removed them.

[steveklabnik]

To make this concrete, here is a PR where I went from regular old asm to naked fn: https://github.com/intermezzOS/kernel/pull/49/files

All that setup code in src/src/asm/interrupt_handlers.asm was able to go away; the duplication between the extern declarations in src/interrupts/src/lib.rs was able to go away... much, much, much nicer.

[jackpot51]

Thanks @steveklabnik for showing the potential of #[naked]. Our experience in Redox was similar

[parched]

Regarding having compile time constants and unmangled labels in it, would it possible to have separate procedural macro that did this? Something like unmangle!(ident) and eval!(expr) that produced string literals. Or is that not possible?

If a general way like that wouldn't work then something like the way armcc does it would be good.

[nagisa]

I do not see how any naked function is not trivially convertible to a global_asm! or vice-versa, though (examples pointing out the contrary much appreciated). For example, you could have a naked! { fn peach() { /* asm goes here */ } which expands to global_asm! as an implementation of naked functions. Making global_asm! just a wrapper over naked functions seems also plausible to some extent.

Otherwise, I agree with Niko, that nobody is making any decisions anytime soon, but would like to add that seeing quality of naked function implementation, its future looks bleak.

[eternaleye]

@nagisa: I agree with you on naked-functions-on-top-of-global_asm!, but I actually disagree on the inverse.

In particular, it relies on doing awful Duff's Device-like tricks, where asm that's syntactically inside a function is treated semantically as if it was global.

If Rust ever grows a principled handling of inline asm, that sounds like an immense obstacle and/or footgun.

[nikomatsakis]

On Fri, Jul 29, 2016 at 03:49:10PM -0700, eternaleye wrote:

@nagisa: I agree with you on naked-functions-over-global_asm, but I actually disagree on the inverse.

To clarify: do you mean "simulating global asm using a dummy naked function is a hack"?

[eternaleye]

@nikomatsakis

To clarify: do you mean "simulating global asm using a dummy naked function is a hack"?

In essence, yes - I feel using naked functions to simulate global asm is a hack, and one that could easily be broken by non-rustc parts of the compilation process to boot.