Incorrect relative jump (rjmp) code generation in latest nightly release for AVR toolchain

[VivekYadav7272]

I've already asked this question on stack exchange where you can see more details.

I tried the following code:

#![no_std]
#![no_main]
#![feature(asm_experimental_arch)]

use core::{arch::asm, hint::black_box, panic::PanicInfo};

use avrd::atmega328p;

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

#[inline(never)]
fn delay(x: u32) {
    for _ in 0..x {
        unsafe {
            asm!("nop");
        }
    }
}

unsafe fn write_reg(reg: *mut u8, val: u8, mask: u8) {
    let reg_val = reg.read_volatile();
    reg.write_volatile((reg_val & !mask) | (val & mask));
}

#[no_mangle]
extern "C" fn main() -> ! {
    const LED_BUILTIN: u8 = 5;
    unsafe {
        let portB_data_direction = atmega328p::DDRB;
        // set it to output mode
        write_reg(portB_data_direction, 1 << LED_BUILTIN, 1 << LED_BUILTIN);
        let portB = atmega328p::PORTB;
        // switch it on, hopefully..
        loop {
            write_reg(portB, 1 << LED_BUILTIN, 1 << LED_BUILTIN);
            delay(500_0000);
            write_reg(portB, 0, 1 << LED_BUILTIN);
            delay(500_0000);
        }
    }
}

The RUSTFLAGS="--emit asm" output is also correct, but the machine code generated is faulty. For now I've switched to nightly-2023-12-11, which seems to work just fine.

For the disassembly of both the --emit asm and the final binary, you can refer to the stack exchange post.
Here's a minimal example that doesn't work on nightly (but works on nightly-2023-12-11):

#![no_std]
#![no_main]

use core::{hint::black_box, panic::PanicInfo};

use avrd::atmega328p;

#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
extern "C" fn main() -> ! {
    const LED_BUILTIN: u8 = 5;
    unsafe {
        let portB_data_direction = atmega328p::DDRB;
        // set it to output mode
        *portB_data_direction |= 1 << LED_BUILTIN;
        let portB = atmega328p::PORTB;

        loop {
            *portB ^= 1 << LED_BUILTIN;
            for i in 0..500_000 {
                black_box(i);
            }
            *portB ^= 1 << LED_BUILTIN;
            for i in 0..500_000 {
                black_box(i);
            }
        }
    }
}

[edgar-bonet]

The TLDR of the referenced discussion is that a Rust loop that looks in essence like this:

let portB = atmega328p::PORTB;  // A microcontroller's I/O port
loop {
    portB.write_volatile(portB.read_volatile() | (1<<5));   // set bit 5 of PORTB
    delay(500_0000);
    portB.write_volatile(portB.read_volatile() & ~(1<<5));  // clear bit 5 of PORTB
    delay(500_0000);
}

gets translated by --emit asm into this:

loop:
    sbi  PORTB, 5  ; set bit 5 of PORTB
    call delay
    cbi  PORTB, 5  ; clear bit 5 of PORTB
    call delay
    rjmp loop      ; relative jump to the start of the loop

which is correct. However, direct translation to machine code yields something that disassembles into this:

    sbi  PORTB, 5  ; set bit 5 of PORTB
loop:              ; <- wrong place
    call delay
    cbi  PORTB, 5  ; clear bit 5 of PORTB
    call delay
    rjmp loop      ; relative jump to the wrong place

This also affects conditional branches (seen on brcs, breq) which, just like rjmp, use PC-relative addressing.

[Patryk27]

This was fixed over llvm/llvm-project#106722 and the newest rustc emits correct code 🙂

[jfrimmel]

I'll add a regression test.

@rustbot claim