Repository navigation
The asm! macro incorrectly zeroes high byte register if both high and low byte registers are used for input, and the low byte input value is zero. #97646
Description
STR:
Compile the following code for 32-bit target (e.g. i686-unknown-linux-gnu or i686-pc-windows-msvc) in release mode:
use std::arch::asm;
unsafe fn int_21h(al_mode: u8) -> Result<u16, u16> {
let mut ax: u16;
let mut flags: u8;
asm!(
"int 0x21",
"mov {ax:x}, ax",
"lahf",
ax = out(reg) ax,
in("ah") 0x3du8,
in("al") al_mode,
in("edx") 0u32,
lateout("ah") flags,
lateout("al") _,
);
if flags & 0x01 == 0 {
Ok(ax)
} else {
Err(ax)
}
}
fn main() {
let x = unsafe { int_21h(0) }.unwrap();
println!("{}", x);
}$ cargo build --target i686-unknown-linux-gnu --releaseLook at the final machine code:
$ objdump -d target/i686-unknown-linux-gnu/release/test_reg_bytes | grep -B 5 "int "
514a: 5b pop %ebx
514b: b4 3d mov $0x3d,%ah
514d: 31 d2 xor %edx,%edx
514f: 31 c0 xor %eax,%eax
5151: 81 c3 62 fd 04 00 add $0x4fd62,%ebx
5157: cd 21 int $0x21AR: As you can see, eax is xored after ah was set to input 0x3d value.
ER: Either the compiler should prevent such high and low byte register usage and refuse to compile such code, either it should not clear ah when it is trying to clear al.
Activity
[-]The asm! macro incorrectly zeroes high byte register if both high and low byte registers are used for input, and low byte input value is zero.[/-][+]The asm! macro incorrectly zeroes high byte register if both high and low byte registers are used for input, and the low byte input value is zero.[/+]asquared31415 commentedon Jun 2, 2022
Minimal reproduction:
godbolt with target
Requires opt-level 1 or greater to reproduce otherwise the zeroing of
eaxgets done first, which is correct. This is possibly a buggy optimization?In 1.60.0 this code started being accepted by #93868
Reproduces in all stable versions since 1.60.0, up to nightly 2022-06-02
talchas commentedon Jun 2, 2022
This is an LLVM breakage, and the equivalent C syntax is
which is broken in both clang and gcc, though in different ways. In clang which write wins depends on the ordering of the constraints like in rust (unsurprising), in gcc it depends on the order of the writes to the register variables, since those are somewhat an actual thing (despite the docs saying no guarantees are made for anything other than their use with inline asm).