mipsel-sony-psx - potential load delay slot issue

[JaberwockySeamonstah]

I am working on making a game for the PS1 (--target mipsel-sony-psx), and I'm experiencing an issue where an Optional is guaranteed to be Some but the check is_some will return false. Using the debugger from Duckstation (PS1 emulator) we where able to see that the Optional was not yet loaded to the register at the time of the check, which is why we assume it could be a load delay slot issue.

Sadly we have not found a small, simple code example yet that can reproduce the issue. The code that shows the behavior runs in the interrupt handler of the PS1 and relies on the serial port. The snippet below gives a rough overview.

• CONTROLLERS_A is a global array with CONTROLLER_SLOT_COUNT = 1 many elements
  • ControllerSlot::new provides Some configuration and None controller
  • ControllerSlot::configuration will never change and is only set by the const ControllerSlot::new
  • The ControllerSlot::controller is used in the main thread
• asm label planschi: aims at the check that will fail
• update_controller is executed in the interrupt handler

We could observe the following behaviors:

• Adding a nop after asm label planschi: can fix the check
• Setting CONTROLLER_SLOT_COUNT = 2 will reliably fix the issue
• Replacing the array of size CONTROLLER_SLOT_COUNT = 1 with a single global ControllerSlot instance will also fix the issue reliably

pub_global!(CONTROLLERS_A, [ControllerSlot; CONTROLLER_SLOT_COUNT], [const {ControllerSlot::new()}; CONTROLLER_SLOT_COUNT]);

pub struct ControllerSlot {
    controller:    Option<RawController>,
    configuration: Option<Configuration>,
}

fn update_controller() {
    let mut serial_connection = SerialConnection::activate();
        process_port(&mut serial_connection, CONTROLLERS_A.as_mut());
    serial_connection.deactivate();
}

fn process_port(serial_connection: &mut SerialConnection, port_slots: &mut [ControllerSlot; CONTROLLER_SLOT_COUNT]) {
    for slot in port_slots.iter_mut() {
        process_controller(serial_connection, &mut slot.controller, &slot.configuration, 0);
    }
}

fn process_controller(serial_connection: &mut SerialConnection, controller: &mut Option<RawController>, configuration: &Option<Configuration>, slot: u8) {
    if let Some(existing_controller) = controller {
        if let Err(_) = process_existing_controller(serial_connection, existing_controller, configuration, slot) {
            *controller = None;
        }
    }
//...

#[allow(named_asm_labels)]
fn process_existing_controller(serial_connection: &mut SerialConnection, controller: &mut RawController, configuration: &Option<Configuration>, slot: u8) -> Result<(), SerialConnectionError> {
    match controller.get_state() {
        ControllerState::New    => {
            unsafe { asm!("planschi:"); }
            if configuration.is_some() {
                if serial_connection.enter_config_mode(slot, true).is_ok() {
                    controller.set_config_mode();
                    return Ok(());
                }
            }
            
            controller.set_stable();
            Ok(())
        },
        ControllerState::InConfigMode(current_config) => {
//...

To not leave you empty handed I uploaded the assembly and the LLVM bit code files for each case. They all include the asm label planschi:.

• The original (CONTROLLER_SLOT_COUNT = 1) faulty case can be found here.
• The good case with CONTROLLER_SLOT_COUNT = 2 can be found here.
• The other good case without the array can be found here.

Meta

rustc +psx --version --verbose:

rustc 1.92.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.92.0-dev
LLVM version: 21.1.3

Since I am working on making a game for the PS1 (--target mipsel-sony-psx), I had to build rust from source with the following command and config.toml:

profile   = "compiler"
change-id = 999999

[llvm]
optimize         = true
download-ci-llvm = false

[rust]
optimize = true
lld      = true

[build]
build-stage = 1
#The tripple for the bootstrap, this must be one that already exists as pre-compiled
build = "x86_64-unknown-linux-gnu"
#The tripple for the host (computer running the build)
host  = ["x86_64-unknown-linux-gnu"]
#The tripple for the output 
target = ["mipsel-sony-psx"]

command: ./x.py build rustc compiler/rustc_driver compiler/rustc_driver_impl library/core && ./x.py build library --target x86_64-unknown-linux-gnu && ./x.py build library src/tools/rust-analyzer src/tools/rust-analyzer/crates/proc-macro-srv-cli --target x86_64-unknown-linux-gnu --stage 2

This is my first time opening such an issue, any advice on how I can help with this is much appreciated.

[Noratrieb]

@ayrtonm as the maintainer for this target.
The most important thing for debugging these issues is usually having a more minimal example. It might be hard, but it's extremely valuable for debugging it. Another approach is to try to selectively disable LLVM passes until the issue disappears, which may or may not be helpful.
Another important thing is ensuring that the code does not have UB and therefore the bug isn't in the code itself. You mention interrupt handlers. Do you perform adequate synchronization between the interrupt handler and the outside code?

[workingjubilee]

@JaberwockySeamonstah what does pub_global!(CONTROLLERS_A, [ControllerSlot; CONTROLLER_SLOT_COUNT], [const {ControllerSlot::new()}; CONTROLLER_SLOT_COUNT]); actually expand to, in Rust?

[JaberwockySeamonstah]

@JaberwockySeamonstah what does pub_global!(CONTROLLERS_A, [ControllerSlot; CONTROLLER_SLOT_COUNT], [const {ControllerSlot::new()}; CONTROLLER_SLOT_COUNT]); actually expand to, in Rust?

@workingjubilee here is what the macro does, the issue also occurs with "normal" static mut arrays:

#[repr(transparent)]
pub struct UncheckedSyncUnsafeCell<T: ?Sized>(core::cell::UnsafeCell<T>);

impl<T> UncheckedSyncUnsafeCell<T> {
    pub const fn from(element: T) -> UncheckedSyncUnsafeCell<T> {
        UncheckedSyncUnsafeCell(core::cell::UnsafeCell::new(element))
    }

    pub const fn as_mut(&self) -> &mut T {
        unsafe{&mut *self.0.get()}
    }

    pub const fn as_ref(&self) -> &T {
        unsafe{&*self.0.get()}
    }
}
unsafe impl<T> Sync for UncheckedSyncUnsafeCell<T> {}

macro_rules! global {
    ($name: ident, $type: ty, $value: expr) => {
        static $name: $crate::support::UncheckedSyncUnsafeCell<$type> = $crate::support::UncheckedSyncUnsafeCell::from($value);
    };
}

(Comments removed to make it more readable)

---

Do you perform adequate synchronization between the interrupt handler and the outside code?

@Noratrieb I modified the code so that the main thread never uses the configuration member at all, even moved the call out of the interrupt handler into the main thread. Both actions changed nothing... My partner said I should mention that the hardware has a single physical thread and the access was isolated.

So - I spend more time trying to reproduce the issue and I lose my mind...
The original project (puddle-app please do not judge :c) is referencing the controller code (and everything PS1 related) through another local project, the puddle-sdk.

[package]
name = "puddle-app"
version = "0.1.0"
edition = "2024"

[dependencies]
puddle-sdk = {version = "*", path = "../puddle-sdk"}

So I created another project (puddle-single) that is a heavily reduced version of the puddle-app but instead of using puddle-sdk I just copied the files needed and added them as modules. I then removed functionality until the issue appeared fixed. I then reduced puddle-app (which depends on puddle-sdk) to the same level but the issue never disappeared! Comparing the assembly code, it had significant differences. But the source code is effectively identical.

I'm not experienced enough with Rust to know what that means, but I always thought that the crates get compiled like they are directly included - like a header only library in C/C++

[Noratrieb]

Crates get compiled separately (except for generics and #[inline] functions) like different .c files, so it does matter in which crate you put the code

[tgross35]

Does optimization level make a difference here? That may help narrow things down. If so, +1 to Nora's suggestion of turning LLVM passes off until the issue doesn't reproduce, which would at least give you a diff of the .ll file to point out the problem area, and maybe figure out what assumptions it's relying on that turn out to be incorrect.

[JaberwockySeamonstah]

I will try a debug build next. I feel silly for not having thought of this earlier. I will add a comment when I tried, sadly I don’t have time until later.

How can I obtain the list of active LLVM passes? And how can I turn them off?

[tgross35]

The names are listed at https://llvm.org/docs/Passes.html, "Transform Passes" are the interesting bits here. You can then run with e.g. -Cno-prepopulate-passes -Cpasses='sroa,loop-unroll' to disable the default pass list then define your own.

Looking at the opt pipeline view on godbolt is a good way to get a feel for what's going on https://rust.godbolt.org/z/3or58W9c1. (filters -> hide inconsequential passes is helpful when you're actually trying to see the transforms)