Support using const pointers in asm const operand

[nbdd0121]

Implements RFC#3848 with tracking issue #128464

This adds support of const pointers for asm const in addition to plain integers.

The inline asm! support is implemented using i constraint, and the global_asm! and naked_asm! support is implemented by inserting symbol + offset and make symbol compiler-used. For unnamed consts, it will create additional internal & hidden symbols so that they can be referenced by global_asm.

The feature is also implemented for GCC backend but it's untested.

[rustbot]

r? @fmease

rustbot has assigned @fmease.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[fmease]

r? codegen

[compiler-errors]

r? compiler-errors

[rustbot]

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[compiler-errors]

Please add more doc comment explaining the significance of the difference between Interpolate and Const for backends. It begs the question for why we ever turn const operands into strings, for example.

[nbdd0121]

Added some explaination. Technically we should be able to use Const for integers, although I am a bit conservative here and don't want to change how existing things work.

This might also be useful to have in the future if we decided to add interpolate "some CTFE string to be interpolated" new type of operand.

[bors]

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

[traviscross]

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

[bors]

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

[workingjubilee]

// x86_64: mov al, byte ptr [{{.*}}anon{{.*}}]

What was the expansion you observed?

[nbdd0121]

mov al, byte ptr [.Lanon.2e8c0013b01edcd3779e8174c2338a00.0]

[bors]

💔 Test failed - checks-actions

[nbdd0121]

Looks like the i constraint doesn't work for GOT-rebased relocation, which x86 use for PIE and we enable PIE by default. We need to either:

• Say this works only with static relocation-model on x86, or
• Generate symbol + offset ourselves, like global_asm implementation.

[samueltardieu]

Oh, it failed bors but was not marked
@bors r-

[bors]

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

[Darksonn]

Looks like the i constraint doesn't work for GOT-rebased relocation

I've been playing around with this a bit, and I think the i operand works as long as using the symbol name would work. For example, this breaks:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int *a;

    __asm__ (
        "movabs %1, %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%p\n", (void *)a);

    return 0;
}

/usr/bin/ld: /tmp/ccptrDbi.o: warning: relocation in read-only section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

But when we make it rip-relative, it works:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int *a;

    __asm__ (
        "movabs %1 - ., %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%p\n", (void *)a);

    return 0;
}

0xec3

We can even force it to generate a GOT-entry with the address of FORTY_TWO and then look up the value through it:

#include <stdio.h>

static const int FORTY_TWO = 42;

int main(void) {
    const int **a;

    __asm__ (
        "leaq (%c1)@GOTPCREL(%%rip), %0"
        : "=r" (a)
	: "i" (&FORTY_TWO)
    );

    printf("%i\n", **a);

    return 0;
}

42

This is exactly the same scenario as when writing FORTY_TWO would work as far as I can tell. Is there something I'm missing?

[nbdd0121]

It works in x64 but not in x86.

EDIT: Looks like it works in GCC for not Clang/LLVM: https://godbolt.org/z/YodbxxMeY

[Darksonn]

Ah, that's what I get for testing it with gcc.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-log-analyzer]

The job aarch64-gnu-llvm-20-1 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- [ui] tests/ui/asm/const-refs-to-static.rs stdout ----

error: test compilation failed although it shouldn't!
status: signal: 6 (SIGABRT) (core dumped)
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/asm/const-refs-to-static.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/aarch64-unknown-linux-gnu/stage2" "--target=aarch64-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/aarch64-unknown-linux-gnu/test/ui/asm/const-refs-to-static" "-A" "unused" "-W" "unused_attributes" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/aarch64-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
rustc-LLVM ERROR: out of memory
Allocation failed
------------------------------------------