Compile Error on AVR atmega328p with global_asm! in lib.rs

[xjnxjnxjn]

This is my first issue, so I'm not sure if this is the right place to report or if it is reported already.

Also formatting this issue is new to me ...

I'm on Rust with AVR atmega328p, using

nightly-2024-11-12-aarch64-unknown-linux-gnu (default)
rustc 1.84.0-nightly (81eef2d36 2024-11-11)

I use "global_asm!" macro which compiles Ok in a bin main.rs and gives a compile error in a lib lib.rs.

The error is

error: <inline asm>:2:5: instruction requires a CPU feature not currently enabled
    x:
    jmp x
   ^

The source in both, main.rs and lib.rs is

//
global_asm!(r#"
   x:
   jmp x
"#);

To test, I have two crates, one to test as --bin with main.rs, one to test as --lib with lib.rs

Both crates have .cargo/config.toml

[build]
target = "avr-atmega328p.json"

[target.avr-atmega328p]
rustflags = [
    #
    "-Clink-arg=-nostartfiles",
]

[unstable]
build-std = ["core"]

Both have Config.toml

[package]
name = "..."
edition = "2021"

[dependencies]

[profile.release]
panic = "abort"
lto = true

The main.rs in the bin test crate :

//!
#![no_std]
#![no_main]
//
#![allow(unused_imports)]
//
#![feature(asm_experimental_arch)]

use core::arch::{ asm, global_asm };

//
global_asm!(r#"
   x:
    jmp x
"#);

///
use core::panic::PanicInfo;
#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! {
    loop {
    }
}

... compiles and links fine !

The lib.rs in the lib test crate :

//!
#![no_std]
//
#![allow(unused_imports)]
//
#![feature(asm_experimental_arch)]

use core::arch::{ asm, global_asm };

//
global_asm!(r#"
   x:
   jmp x
"#);

... and gives compile error

error: <inline asm>:2:5: instruction requires a CPU feature not currently enabled
    jmp x
    ^

Command for both crates is cargo build --release

./home/rust/rust-repos/rustc/rust/src/llvm-project/llvm/lib/Object/ModuleSymbolTable.cpp

I've tracked it down to llvm :

llvm-project/llvm/lib/Object/ModuleSymbolTable.cpp

static void initializeRecordStreamer(...) 
{
...
  std::unique_ptr<MCSubtargetInfo> STI(
      T->createMCSubtargetInfo(TT.str(), "", ""));
...
}

The ("","") forces the feature map to go to the lowest for AVR and does not honor, that "atmega328p" features should be used.

Ich I patch it to

  std::unique_ptr<MCSubtargetInfo> STI(
      T->createMCSubtargetInfo(TT.str(), "atmega328p", ""));

it compiles fine :) But this is not a Solution

So here I stuck ...

br
xjn

[tgross35]

I think @Patryk27 has been working on the AVR targets, there are some interesting interactions with target features on this platform iirc.

Also @xjnxjnxjn would you mind formatting the issue description? It's kind of difficult to read currently, Just wrap the code in fences like

```rust
// ...
```

```toml
# ...
```

```
Error text ...
```

[tgross35]

Actually it looks like @jfrimmel has been working on AVR assembly (based on #131323)

[xjnxjnxjn]

... some formatting

[xjnxjnxjn]

Actually it looks like @jfrimmel has been working on AVR assembly (based on #131323)

Thx for the format hints, i've done my best now.

I'm new at github, so do i have to inform/ask @jfrimmel or @Patryk27 to have a look at it ?

Or are they informed by github or by themselve looking at AVR related issues ?

[tgross35]

Actually it looks like @jfrimmel has been working on AVR assembly (based on #131323)

Thx for the format hints, i've done my best now.

Thanks! Much better now :)

I'm new at github, so do i have to inform/ask @jfrimmel or @Patryk27 to have a look at it ?

Or are they informed by github or by themselve looking at AVR related issues ?

Using @ sends the user a notification, so somebody will probably take a look when they get the chance. (Note that AVR isn't the most active target, I'm not sure how active the maintainers are).

If you would be willing to look into this yourself a bit, you could try the following:

• Try to reproduce this with rustc directly, not cargo. Passing --crate-type=lib/--crate-type=bin is how Cargo controls binary output.
• If you are having trouble reproducing, use cargo -vv to print what exactly it is doing
• If you are having trouble building core with rustc, you can mark your crate #![no_core] and paste this file at the top of the file you want to build https://github.com/rust-lang/rust/blob/824759493246ee383beb9cd5ceffa0e15deb9fa4/tests/auxiliary/minicore.rs
• After you get a rustc repro, run with --emit=llvm-ir for the binary and library versions. If the target features and asm are different, we can figure out why rustc is doing that. If they are the same but LLVM is reacting differently for some reason, that would be an LLVM bug.

[xjnxjnxjn]

I've done following on lib- and bin-crate

cargo rustc -vv --release -- --emit=llvm-ir

llvm-ir result for bin-crate is

; ModuleID = 'avr_test_bin_jmp.15164f7bfba025d7-cgu.0'
source_filename = "avr_test_bin_jmp.15164f7bfba025d7-cgu.0"
target datalayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
target triple = "avr-unknown-unknown"

module asm ""
module asm "    .global x"
module asm "    x:"
module asm "    jmp x"

; Function Attrs: nofree norecurse noreturn nosync nounwind memory(none)
define dso_local void @main() unnamed_addr addrspace(1) #0 {
start:
  br label %bb1

bb1:                                              ; preds = %bb1, %start
  br label %bb1
}

attributes #0 = { nofree norecurse noreturn nosync nounwind memory(none) "target-cpu"="atmega328p" }

!llvm.ident = !{!0}

!0 = !{!"rustc version 1.84.0-nightly (81eef2d36 2024-11-11)"}

llvm-ir result for lib-crate is

; ModuleID = 'avr_test_lib_jmp.6c92e6abff26f32-cgu.0'
source_filename = "avr_test_lib_jmp.6c92e6abff26f32-cgu.0"
target datalayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8"
target triple = "avr-unknown-unknown"

module asm ""
module asm "    .global x"
module asm "    x:"
module asm "    jmp x"

!llvm.ident = !{!0}

!0 = !{!"rustc version 1.84.0-nightly (81eef2d36 2024-11-11)"}

I've tried to add

-Ctarget-cpu=atmega328p

to the lib compile command, no change.

[Patryk27]

Hi, I've just tried replicating the issue and in my case the compilation passes without any errors - could you prepare an example repository I could git clone and cargo build --release locally?

[xjnxjnxjn]

Hi, I've just tried replicating the issue and in my case the compilation passes without any errors - could you prepare an example repository I could git clone and cargo build --release locally?

@Patryk27

git clone https://github.com/xjnxjnxjn/avr-test-global-asm.git

I'm on

nightly-2024-11-12-aarch64-unknown-linux-gnu (default)
rustc 1.84.0-nightly (81eef2d36 2024-11-11)

[tgross35]

Could you try updating to the latest nightly? Might not make a difference, but there have been a handful of changes to how we codegen asm in the past few months (mostly naked_asm! and not global_asm! though).

[xjnxjnxjn]

Could you try updating to the latest nightly? Might not make a difference, but there have been a handful of changes to how we codegen asm in the past few months (mostly naked_asm! and not global_asm! though).

Switched to

nightly-aarch64-unknown-linux-gnu (default)
rustc 1.86.0-nightly (824759493 2025-01-09)

no difference, same error, same *.ll files.

[Patryk27]

This seems to be a rustc issue - it fails to propagate some target information to LLVM; a very similar thing happens for RISC-V:

• Compilation error about RISC-V H extension #111637
• Can't use vmsr instruction in global_asm! on armv7r-none-eabihf without codegen-units=1 #127269
• global_asm! macro causes non-fatal errors to be printed during compilation for some RISC-V extension instructions when targeting the GC extensions #80608

Turning LTO off "solves" the problem.

Edit: apparently it might be an LLVM issue as well (llvm/llvm-project#61991) - in any case, it's not AVR-specific, it can happen for all targets.

[xjnxjnxjn]

Turning LTO off "solves" the problem.

Ok, I'll use this until the problem is solved.

Edit: apparently it might be an LLVM issue as well (llvm/llvm-project#61991) - in any case, it's not AVR-specific, it can happen for all targets.

Yes, this seems to be the underlying issue.

I'm a bit proud, I've found the "error line" in the LLVM source by myself :)
Unfortunately I had no idea how to search or solve the error ...

Is there a way to get informed, if this issue is solved by LLVM and/or rustc ?

Thx again.

[tgross35]

Is there a way to get informed, if this issue is solved by LLVM and/or rustc ?

There is a "subscribe" button on the right side of any issue or PR. If you click it, you should get a notification/email whenever it is updated or closed (similar to what you are likely getting for this one).

Welcome to GitHub :)