Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add size and len for PageRange, PhysFrameRange, PageRangeInclusive and PhysFrameRangeInclusive #491

Merged
merged 1 commit into from
Jul 22, 2024

Conversation

Wasabi375
Copy link
Contributor

No description provided.

Copy link
Member

@Freax13 Freax13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your contribution!

src/structures/paging/frame.rs Outdated Show resolved Hide resolved
src/structures/paging/frame.rs Outdated Show resolved Hide resolved
@Wasabi375
Copy link
Contributor Author

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),
            );
        }
    }
}

@Freax13
Copy link
Member

Freax13 commented Jul 14, 2024

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.

@Freax13
Copy link
Member

Freax13 commented Jul 14, 2024

Do you mind waiting until #492 is merged or do you need this to be merged sooner?

@Wasabi375
Copy link
Contributor Author

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.

@Freax13
Copy link
Member

Freax13 commented Jul 22, 2024

Could you rebase this onto the latest master branch?

@Freax13 Freax13 merged commit a59bf9f into rust-osdev:master Jul 22, 2024
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants