codegen #[naked] functions using global asm

[folkertdev]

tracking issue: #90957

Fixes #124375

This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of #[naked] functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).

I discussed this approach with @Amanieu and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.

Combined with #127853, if both accepted, I think that resolves all steps from the tracking issue.

r? @Amanieu

[tgross35]

On the tracking issue a naked_asm! macro was proposed that would closer follow global_asm! (cc @Lokathor since you liked this idea). It sounds like this PR effectively turns #[naked] + asm! into exactly what naked_asm would do, so that would no longer be necessary?

The changes in this PR seem like good direction.

[Lokathor]

I think that separately from any internal implementation change, the surface syntax of rust should use naked_asm separately from asm, because the two have different enough user interface and semantics.

[folkertdev]

I agree that it is still a good idea to add naked_asm! as a public api, if only because it makes the documentation much more straightforward: instead of having to explain the interaction between #[naked] and asm!, we just mandate that #[naked] must use a naked_asm! block and the naked_asm! docs can give the exact details and restrictions.

But that is separate from how the codegen works, which is what this PR is for.

[folkertdev]

I've not been able to actually generate code that triggers this if. Visibility just seems to always be Default. So this is entirely untested at the moment.

[tgross35]

For anything like this, drop a question on Zulip https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp. Unfortunately that enum doesn't seem to be very well documented

[bjorn3]

This function can probably just take TyCtxt.

[bjorn3]

Ah, this layout_of call uses the CodegenCx. This is during codegen though, so RevealAllLayoutCx (a wrapper around TyCtxt) is enough: https://github.com/rust-lang/rustc_codegen_cranelift/blob/b70ad2defd4bb5fba6af7958893e22be0f33dfdd/src/common.rs#L450-L518 Maybe it should be uplifted out of cg_clif?

[folkertdev]

seems useful, should that be part of this PR though?

[bors]

☔ The latest upstream changes (presumably #128298) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #125443) made this pull request unmergeable. Please resolve the merge conflicts.

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[folkertdev]

I think this is as far as I can take it without some external feedback

@rustbot ready

[Amanieu]

Overall LGTM. I'm still not 100% sure about the linkage-related things, but I think it's good enough to merge. We can handle any issues that are discovered later.

[Amanieu]

Also test that at the end of each function the assember mode is restored to the default for the target.

[folkertdev]

what are these assembler modes based on? I don't see .arm here at all, and for thumb only thumb_function appears to be used.

https://godbolt.org/z/rjjc4KxnG

and even then only at the start, not at the end

        .section        .text.test_thumb,"ax",%progbits
        .globl  test_thumb
        .p2align        1
        .type   test_thumb,%function
        .code   16
        .thumb_func
test_thumb:
.Lfunc_begin0:
        .fnstart
        .cfi_sections .debug_frame
        .cfi_startproc
        .file   1 "/app" "example.rs"
        .loc    1 19 5 prologue_end
        bx      lr
        .inst.n 0xdefe
.Lfunc_end0:
        .size   test_thumb, .Lfunc_end0-test_thumb
        .cfi_endproc
        .cantunwind
        .fnend

[folkertdev]

this is confusing, the assert is triggered in this example

    let is_thumb = tcx.sess.unstable_target_features.contains(&sym::thumb_mode);

    let attrs = tcx.codegen_fn_attrs(instance.def_id());
    let link_section = attrs.link_section.map(|symbol| symbol.as_str().to_string());
    let align = attrs.alignment.map(|a| a.bytes()).unwrap_or(4);

    let (arch_prefix, arch_suffix) = if is_arm {
        (
            match attrs.instruction_set {
                None => match is_thumb {
                    true => ".thumb\n.thumb_func",
                    false => ".arm",
                },
                Some(InstructionSetAttr::ArmT32) => {
                    assert!(is_thumb);
                    ".thumb\n.thumb_func"
                }

that conflicts with

/// Computes the set of target features used in a function for the purposes of
/// inline assembly.
fn asm_target_features(tcx: TyCtxt<'_>, did: DefId) -> &FxIndexSet<Symbol> {
    let mut target_features = tcx.sess.unstable_target_features.clone();
    if tcx.def_kind(did).has_codegen_attrs() {
        let attrs = tcx.codegen_fn_attrs(did);
        target_features.extend(attrs.target_features.iter().map(|feature| feature.name));
        match attrs.instruction_set {
            None => {}
            Some(InstructionSetAttr::ArmA32) => {
                // FIXME(#120456) - is `swap_remove` correct?
                target_features.swap_remove(&sym::thumb_mode);
            }
            Some(InstructionSetAttr::ArmT32) => {
                target_features.insert(sym::thumb_mode);
            }
        }
    }

    tcx.arena.alloc(target_features)
}

so information is getting lost somewhere I think?

[diondokter]

I don't have deep assembly knowledge, but I do know a little bit about the hardware.

It's good to separate out two things:

• There is the hardware that is machine code
• Then there is the instructions making up that machine code

The hardware can run in two modes: Arm mode and Thumb mode. Some cpus can run both and some can only run one, but they all behave the same way. The cpus can switch which mode they're running in at runtime on the fly.
But important to know is that the hardware does not know what machine code it is running. It must be told when to switch.

Afaik, this can only be done in branch (b) instructions that also have the x (for eXchange) in them, like bx and blx. All functions (and I guess labels) are 16-bit aligned. So the lowest bit has no significance in determining the address to jump to. Instead the lowest bit is known as the 'thumb' bit. On a bx instruction, if the thumb bit is not set then the cpu will switch to (or remain in) Arm mode. If the thumb bit is set, then the cpu will switch to Thumb mode.

This is where .thumb_func comes in. It implies a .thumb directive and gives information to the assembler and linker that this is a thumb symbol and as such the thumb bit must be set when branching to it. This is called 'interworking' and there's a bit more to it because the cpu must also possibly switch modes when returning from a functions.

Then over to the instructions themselves. They can be compiled to machine code and are done so either using Arm or Thumb representation. In the assembly you can tell the assembler which one is to be used.

When adding .arm or .code 32, it means the instructions after it are to be assembled using the Arm mode.
When adding .thumb or .code 16, then the instructions will be encoded as Thumb.

Then another thing is which syntax is used. It can be .syntax [unified | divided]. When unified is used, then a newer assembly is used that can specify both Arm and Thumb instructions. The older divided has slightly different syntax for the two modes. I'm not sure what the default is when you don't specify it. But I believe that when looking at the instructions using e.g. objdump it's always shown with the unified syntax. I don't know... I also don't know if it's relevant for you now.

I found this nice page with directives with some short explanations:
https://sourceware.org/binutils/docs/as/ARM-Directives.html

Note though that for .thumb_func it says: "This directive is not necessary when generating EABI objects. On these targets the encoding is implicit when generating Thumb code."
I think that may not be true for the assembly we put into LLVM and that .thumb_func is required. But I've not tested that.

TLDR:

• .arm or .code 32 switch the instruction encoding to Arm mode
• .thumb or .code 16 switch the instruction encoding to Thumb mode
• Use .thumb_func to mark a symbol as a Thumb symbol. It sets up the 'interworking' so the cpu will switch to thumb mode when branching to the symbol or returning to it. It also implies .thumb

I hope this helps understanding! (Or at least didn't make it worse)

[folkertdev]

nice, I've just added two

//@ revisions: arm-mode thumb-mode
//@ [arm-mode] compile-flags: --target armv5te-none-eabi
//@ [thumb-mode] compile-flags: --target thumbv5te-none-eabi

// <snip>

// CHECK: .arm
// CHECK-LABEL: test_unspecified:
// CHECK: bx lr
// CHECK: .popsection
// arm-mode: .arm
// thumb-mode: .thumb

i.e., on both arm and thumb mode, the .code value is reset to the default for the target at the end of the global asm block

That seems to fix the final open question?

[bors]

☔ The latest upstream changes (presumably #130066) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

☔ The latest upstream changes (presumably #128651) made this pull request unmergeable. Please resolve the merge conflicts.