Stream: t-compiler/const-eval

Topic: statx shim


Christian Poveda (Dec 01 2019 at 05:10, on Zulip):

Hello everyone, so I've resumed my work on https://github.com/rust-lang/miri/issues/999. First I wanted to be sure that I got the API right (http://man7.org/linux/man-pages/man2/statx.2.html) so I'm trying to grab struct statx *statxbuf and write a bunch of zeroes to it in the same way is done in shims/time.rs. However I'm not able to deref the operand because the operand does not have a memory location, it is just an integer:

OpTy { op: Immediate(Scalar(0x0000000000020150)), layout: TyLayout { ty: i64, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Int(I64, true), valid_range: 0..=18446744073709551615 }), largest_niche: None, align: AbiAndPrefAlign { abi: Align { pow2: 3 }, pref: Align { pow2: 3 } }, size: Size { raw: 8 } } } }

In contrast with the operand used in time:

OpTy { op: Immediate(Scalar(AllocId(596).0x0[<untagged>])), layout: TyLayout { ty: *mut libc::unix::timespec, details: LayoutDetails { variants: Single { index: 0 }, fields: Union(0), abi: Scalar(Scalar { value: Pointer, valid_range: 0..=18446744073709551615 }), largest_niche: None, align: AbiAndPrefAlign { abi: Align { pow2: 3 }, pref: Align { pow2: 3 } }, size: Size { raw: 8 } } } }

So what should I try here? Maybe to force_ptr it and then build a MPlaceTy with that?

oli (Dec 01 2019 at 12:18, on Zulip):

Yea, always use force_ptr if you expect to deref

Christian Poveda (Dec 01 2019 at 14:25, on Zulip):

uhhh i think I'm almost there... but I'm having trouble getting the correct layout

Christian Poveda (Dec 01 2019 at 14:26, on Zulip):

the problem is that when I try to get the layout from libc i get https://docs.rs/libc/0.2.63/libc/fn.statx.html instead of https://docs.rs/libc/0.2.63/libc/struct.statx.html because they both are libc::statx

oli (Dec 01 2019 at 14:43, on Zulip):

I have a horrible idea: grab the type from the function argument.

Christian Poveda (Dec 01 2019 at 14:54, on Zulip):

I solved it grabbing it from another unambiguous path:

        let statx_ty = this.resolve_path(&["libc", "unix", "linux_like", "linux", "gnu", "statx"])?.ty(*this.tcx);
Christian Poveda (Dec 01 2019 at 14:54, on Zulip):

I have a horrible idea: grab the type from the function argument.

but that would be awesome

oli (Dec 01 2019 at 14:56, on Zulip):

Does that path exist on all platforms?

Christian Poveda (Dec 01 2019 at 14:58, on Zulip):

Does that path exist on all platforms?

probably not... but statx only exists in linux for certain kernel versions

oli (Dec 01 2019 at 15:02, on Zulip):

Oh, right, carry on

Christian Poveda (Dec 01 2019 at 15:02, on Zulip):

well now it runs :P

Christian Poveda (Dec 01 2019 at 15:03, on Zulip):

I mean it no longer crashes because of the terminfo error :P

Christian Poveda (Dec 01 2019 at 15:04, on Zulip):

now that you mention it InterpCx::resolve_path at what level is working? host or target?

oli (Dec 01 2019 at 15:09, on Zulip):

Target

Christian Poveda (Dec 01 2019 at 15:41, on Zulip):

great

Christian Poveda (Dec 03 2019 at 21:42, on Zulip):

do you know why

pub fn int_to_immty_checked<'tcx>(
    int: i128,
    layout: TyLayout<'tcx>,
) -> InterpResult<'tcx, ImmTy<'tcx, Tag>> {
    // If `int` does not fit in `size` bits, we error instead of letting
    // `ImmTy::from_int` panic.
    let size = layout.size;
    let truncated = truncate(int as u128, size);
    if sign_extend(truncated, size) as i128 != int {
        throw_unsup_format!(
            "Signed value {:#x} does not fit in {} bits",
            int,
            size.bits()
        )
    }
    Ok(ImmTy::from_int(int, layout))
}

fails to fit 0x8000 in 16 bits?

Christian Poveda (Dec 03 2019 at 21:45, on Zulip):

it is because its trying to fit it as signed?

oli (Dec 03 2019 at 23:29, on Zulip):

have you tried printing the result of sign_extend?

oli (Dec 03 2019 at 23:30, on Zulip):

I think it creates a 0xFFFF_FFFF_FFFF_FFFF_FFFF_FFFF_FFFF_8000

Christian Poveda (Dec 03 2019 at 23:30, on Zulip):

it is the correct number but with negative sign

oli (Dec 03 2019 at 23:31, on Zulip):

?

oli (Dec 03 2019 at 23:32, on Zulip):

oh right, that's what you are trying to check

oli (Dec 03 2019 at 23:33, on Zulip):

what was the value before truncation? 0x8000 should totally not error in this function

oli (Dec 03 2019 at 23:33, on Zulip):

oh

oli (Dec 03 2019 at 23:33, on Zulip):

wait it should

oli (Dec 03 2019 at 23:34, on Zulip):

because as a i128 that's not a negative number

oli (Dec 03 2019 at 23:34, on Zulip):

so yes, that is supposed to fail

Christian Poveda (Dec 03 2019 at 23:34, on Zulip):

is it there an ImmTy::from_uint or something?

oli (Dec 03 2019 at 23:34, on Zulip):

probably if that's what you want :D

oli (Dec 03 2019 at 23:35, on Zulip):

(I'm not sure what your actual use case is, so this is getting XY-problemy)

Christian Poveda (Dec 03 2019 at 23:35, on Zulip):

Kein problem

Christian Poveda (Dec 03 2019 at 23:35, on Zulip):

with that is enough, I can fix everything with that

Christian Poveda (Dec 03 2019 at 23:36, on Zulip):

I'll add a new method for unsigned ints

Christian Poveda (Dec 04 2019 at 12:43, on Zulip):

(I'm not sure what your actual use case is, so this is getting XY-problemy)

So the problem was that some the values provided by statx are unsigned, and we didn't have a way to provide Immediates that were uints

Last update: Dec 12 2019 at 00:55UTC