New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issue for naked fns (RFC #1201) #32408

Open
nikomatsakis opened this Issue Mar 21, 2016 · 9 comments

Comments

Projects
None yet
8 participants
@nikomatsakis
Contributor

nikomatsakis commented Mar 21, 2016

This is the tracking issue for rust-lang/rfcs#1201.

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

Feedback on its design is required, as well as comparisons with global asm.

@jackpot51

This comment has been minimized.

Contributor

jackpot51 commented Mar 21, 2016

This issue was partially addressed by #29189

@jackpot51

This comment has been minimized.

Contributor

jackpot51 commented Mar 21, 2016

#32410 is an up to date implementation

@ranma42

This comment has been minimized.

Contributor

ranma42 commented Mar 26, 2016

It might be a little late to point it out, but the RFC does not say anything about the interaction between naked functions and unwinding/panics.

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jul 29, 2016

Note that global-asm has also been added, which overlaps somewhat with naked fns.

@mark-i-m

This comment has been minimized.

Contributor

mark-i-m commented Jul 15, 2017

So how exactly do experimental features get stabilized? This is an incredibly useful feature for building an OS, and I would love to see it move forward :)

@nikomatsakis

This comment has been minimized.

Contributor

nikomatsakis commented Jul 17, 2017

@mark-i-m well, if we retrofit this into the "experimental RFC" process that we are experimenting with (so much experimenting!), then the next step would be to take the lessons we've learned from having the feature around and write-up a new RFC that lays out the:

  • final design of the feature, and in particular the various tricky cases and how we decided to resolve them
  • talks about experience in the wild
  • etc

and then we would proceed as normal.

In the case of naked functions, I think if anything my doubts have grown more grave, not less. In particular, I still don't think we can say much with confidence about how Rust code embedded in naked functions is expected to be compiled. Right now it's all pretty darn unspecified, iirc. I'd be interested to see some kind of data points for whether all naked fns in the wild use purely inline assembly, or whether they embed Rust code, and if so, what Rust code they embed (maybe we can define some kind of sensible subset)?

@mark-i-m

This comment has been minimized.

Contributor

mark-i-m commented Jul 18, 2017

@nikomatsakis Here is some code I wrote last weekend for an OS kernel: https://gist.github.com/mark-i-m/361cbcc39769f965b1c419091b9cbf4f

It is mostly assembly, but it does have Rust mixed in. Specifically, it has function calls not just to other naked or inlined functions, but also to normal Rust functions, such as here.

In particular, I still don't think we can say much with confidence about how Rust code embedded in naked functions is expected to be compiled.

Personally, my expectation is that it should compile just like it normally would -- just the prologue/epilogue are left out. For example,

extern "C" fn foo(bar: usize) -> usize {
    bar << 1
}

generates

_ZN10playground3foo17h002f6b2acb4d5b2dE:
.Lfunc_begin2:
	.loc	1 2 0
	.cfi_startproc
	pushq	%rbp
.Ltmp12:
	.cfi_def_cfa_offset 16
.Ltmp13:
	.cfi_offset %rbp, -16
	movq	%rsp, %rbp
.Ltmp14:
	.cfi_def_cfa_register %rbp
	movq	%rdi, -16(%rbp)
.Ltmp15:
	.loc	1 2 0 prologue_end
	movq	-16(%rbp), %rdi
	movq	%rdi, -8(%rbp)
.Ltmp16:
	.loc	1 3 0
	movq	-8(%rbp), %rdi
	shlq	$1, %rdi
	movq	%rdi, -24(%rbp)
	.loc	1 4 0
	movq	-24(%rbp), %rax
	popq	%rbp
	retq

I imagine the naked version would simply be this (I didn't adjust the offsets on the stack):

_ZN10playground3foo17h002f6b2acb4d5b2dE:
.Ltmp15:
	.loc	1 2 0 prologue_end
	movq	-16(%rbp), %rdi
	movq	%rdi, -8(%rbp)
.Ltmp16:
	.loc	1 3 0
	movq	-8(%rbp), %rdi
	shlq	$1, %rdi
@mark-i-m

This comment has been minimized.

Contributor

mark-i-m commented Jul 18, 2017

Oh, and irq_common is another great example! It has a lot of stuff

  • naked
  • inlined
  • inline assembly with outputs to Rust variables, including a pointer to a Rust-defined struct
  • calls a normal Rust function
  • returns !
  • has a panic which should never be called.
@mark-i-m

This comment has been minimized.

Contributor

mark-i-m commented Feb 17, 2018

I guess since embedded is a focus in 2018, this will be revived soon.

One thing to note is that this feature is pretty useless to stabilize before inline asm 😛

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment