Closed Wasabi375 closed 2 months ago
Looks like the latest nightly version is breaking some of the
asm!
instructions. I would fix it, but I'm not sure what the problematic label in the assembly does, so I don't feel qualified :(impl Segment for CS { get_reg_impl!("cs"); /// Note this is special since we cannot directly move to [`CS`]; x86 requires the instruction /// pointer and [`CS`] to be set at the same time. To do this, we push the new segment selector /// and return value onto the stack and use a "far return" (`retfq`) to reload [`CS`] and /// continue at the end of our function. /// /// Note we cannot use a "far call" (`lcall`) or "far jmp" (`ljmp`) to do this because then we /// would only be able to jump to 32-bit instruction pointers. Only Intel implements support /// for 64-bit far calls/jumps in long-mode, AMD does not. #[inline] unsafe fn set_reg(sel: SegmentSelector) { unsafe { asm!( "push {sel}", "lea {tmp}, [1f + rip]", "push {tmp}", "retfq", "1:", // ERROR: avoid using labels containing only the digits `0` and `1` in inline assembly sel = in(reg) u64::from(sel.0), tmp = lateout(reg) _, options(preserves_flags), ); } } }
I just opened #492 to fix that.
Do you mind waiting until #492 is merged or do you need this to be merged sooner?
I dont mind waiting. I will need to use my own branch anyways as I also rely on changes on the next branch. At least I think I do. I currently have a commit from the next branch pinned, so I probably need to merge this change and next for my stuff to work.
Could you rebase this onto the latest master branch?
Looks like the latest nightly version is breaking some of the
asm!
instructions. I would fix it, but I'm not sure what the problematic label in the assembly does, so I don't feel qualified :(