Stream: t-compiler/wg-mir-opt

Topic: popping evaluated frame


Alexander Regueiro (Jul 12 2019 at 03:25, on Zulip):

Hi. Is there any way to either avoid Miri popping the initial frame, or add a hook before its popped off?

Wesley Wiser (Jul 12 2019 at 11:02, on Zulip):

pop_stack_frame() calls Machine::stack_pop(). That's the only existing place I could see being used as a hook. The rest of pop_stack_frame() seems to expect that the initial frame will always be popped so it doesn't look like that's currently configurable.

oli (Jul 12 2019 at 12:14, on Zulip):

priroda prevents the last frame from being popped

Alexander Regueiro (Jul 12 2019 at 14:15, on Zulip):

@oli thanks

Alexander Regueiro (Jul 12 2019 at 14:15, on Zulip):

@Wesley Wiser I'll look at what you said too. Ta.

Alexander Regueiro (Jul 12 2019 at 14:23, on Zulip):

(presumably priroda calls step manually to do. will check soon)

Alexander Regueiro (Jul 12 2019 at 17:52, on Zulip):

Guessing this is the relevant bit: https://github.com/oli-obk/priroda/blob/master/src/step.rs

Alexander Regueiro (Jul 12 2019 at 17:52, on Zulip):

specifically, the step fn there

Alexander Regueiro (Jul 12 2019 at 23:59, on Zulip):

Ah, before_terminator + is_ret seems like a good way to hook onto such events. Not much different from stepping through manually (with is_ret) mind you... thanks for the tips guys.

Alexander Regueiro (Jul 13 2019 at 00:46, on Zulip):

Slightly related question: is it possible to either to exclude or at least recognise drop glue for functions/frames in Miri? It seems stack-popping takes care of cleaning up such locals anyway, and I'd like to know which locals are "live" at the end of a function. (i.e. haven't been moved.)

oli (Jul 13 2019 at 07:35, on Zulip):

You know the liveness of a local by looking at its entry in the frame. StorageDead cleans up all locals that do not need to be live for the entire function. This is reflected in the LocalState iirc

Alexander Regueiro (Jul 13 2019 at 14:03, on Zulip):

I see

Alexander Regueiro (Jul 13 2019 at 14:04, on Zulip):

@oli What about moved locals? Are they reflected/treated differently in the frame state?

oli (Jul 13 2019 at 14:21, on Zulip):

They have storagedead statements

Alexander Regueiro (Jul 13 2019 at 14:52, on Zulip):

@oli Right, so I guess I can't really distinguish between the two? Or somehow avoid having StorageDead statements for ones that are not moved but merely got unused after a certain point?

oli (Jul 13 2019 at 15:48, on Zulip):

No there's no difference

oli (Jul 13 2019 at 15:48, on Zulip):

You can collect the info yourself though

oli (Jul 13 2019 at 15:49, on Zulip):

Visit each statement and when you encounter a visit_local call check the context for moves

Alexander Regueiro (Jul 13 2019 at 15:58, on Zulip):

@oli makes sense. thanks!

Alexander Regueiro (Jul 13 2019 at 16:17, on Zulip):

looks like RequiresStorage in storage_liveness already does something similar to this if I'm not mistaken

oli (Jul 13 2019 at 16:25, on Zulip):

That's static information right? Not dynamic, so a variable that isn't used at all in a specific run will not be treated as unused

Alexander Regueiro (Jul 13 2019 at 16:37, on Zulip):

@oli Ah true. It's dataflow analysis, so static... I think parts like the MoveVisitor can be reused though. It concerns itself with borrows though, which I probably don't need to worry about.

Alexander Regueiro (Aug 20 2019 at 22:28, on Zulip):

Guys, is there any reason for the import style in miri, out of curiosity? That is, "pooling" everything as pub uses in the crate root.

Alexander Regueiro (Aug 20 2019 at 22:28, on Zulip):

and then doing use crate::* in various modules.

RalfJ (Aug 24 2019 at 11:34, on Zulip):

laziness, I guess?

Alexander Regueiro (Aug 24 2019 at 22:47, on Zulip):

laziness, I guess?

hah okay. just checking there wasn't a particular reason... probably right.

RalfJ (Aug 25 2019 at 08:47, on Zulip):

there's many ways to structure your Rust programs, and with the sheer number of imports miri needs I have to say I like this style -- makes it much easier to split code into modules as you dont have to spend 30min teasing the imports apart.

Alexander Regueiro (Aug 26 2019 at 03:27, on Zulip):

Agreed. The only downside is that you lose "structure"... which can be a good or bad thing. But probably not terribly worth maintaining here.

Alexander Regueiro (Aug 27 2019 at 04:24, on Zulip):

@RalfJ is there any way to create values of stdlib types from inside miri (say, implementing an intrinsic)?

RalfJ (Aug 27 2019 at 17:09, on Zulip):

dozens of intrinsics and FFI stubs are already implemented, did you check those?

RalfJ (Aug 27 2019 at 17:09, on Zulip):

look for files called "intrinsics.rs"

Alexander Regueiro (Aug 27 2019 at 18:40, on Zulip):

@RalfJ oh yeah, saw that. nothing there to do with creating values of stdlib types though. just primitive types and pointers.

RalfJ (Aug 27 2019 at 18:52, on Zulip):

oh I see. then I don't think this has been done before.

RalfJ (Aug 27 2019 at 18:52, on Zulip):

there's certainly a way, but you'll have to manually interact with the interpreter APIs: allocate some space, obtain Places for the fields you are about, writing to them, ...

Alexander Regueiro (Aug 27 2019 at 22:26, on Zulip):

@RalfJ okay, I'll have a look, thanks

Alexander Regueiro (Aug 29 2019 at 04:47, on Zulip):

@RalfJ Hmm, would I not simply do this to return a null pointer (of any type), when implementing an intrinsnic?

Alexander Regueiro (Aug 29 2019 at 04:47, on Zulip):
                this.write_scalar(
                    Scalar::ptr_null(this),
                    dest,
                )?;
RalfJ (Aug 29 2019 at 06:42, on Zulip):

that works for intrinsics returning something of pointer type, yes

RalfJ (Aug 29 2019 at 06:43, on Zulip):

of course if it is a reference or Box, that cannot be right^^

Alexander Regueiro (Aug 29 2019 at 18:24, on Zulip):

@RalfJ yeah. It's a *const dyn Debug in fact

Alexander Regueiro (Aug 29 2019 at 18:24, on Zulip):

weird that I'm getting this error then:

thread 'rustc' panicked at 'assertion failed: `(left == right)`
  left: `Size { raw: 8 }`,
 right: `Size { raw: 16 }`: Size mismatch when writing bits', src/librustc_mir/interpret/place.rs:705:21
Alexander Regueiro (Aug 29 2019 at 18:26, on Zulip):

(on that exact call to write_scalar, indeed)

RalfJ (Aug 29 2019 at 18:28, on Zulip):

yeah, ptr_null is ptr-sized

RalfJ (Aug 29 2019 at 18:28, on Zulip):

wide raw pointers are twice as big

RalfJ (Aug 29 2019 at 18:28, on Zulip):

you'll need a ScalarPair where the first component is a ptr_null, and the 2nd points to a valid vtable

RalfJ (Aug 29 2019 at 18:29, on Zulip):

(there's a reason that there is no ptr::null() for unsized types...)

Alexander Regueiro (Aug 29 2019 at 18:29, on Zulip):

ah yes, that makes sennse

Alexander Regueiro (Aug 29 2019 at 18:46, on Zulip):

@RalfJ seems to work now, thanks

RalfJ (Aug 29 2019 at 19:16, on Zulip):

what are you using for the vtable?

Alexander Regueiro (Aug 29 2019 at 19:18, on Zulip):

@RalfJ I just use the *const T argument to the intrinsic fn (but check that T: Debug actually holds first)

Alexander Regueiro (Aug 29 2019 at 19:18, on Zulip):

I think that's okay?

RalfJ (Aug 29 2019 at 19:18, on Zulip):

what is the intrinsic?

RalfJ (Aug 29 2019 at 19:19, on Zulip):

*const T doesnt look like a vtable ptr to me...

Alexander Regueiro (Aug 29 2019 at 19:19, on Zulip):

it's a new one I'm making for the REPL. only available in the REPL. as_debug

Alexander Regueiro (Aug 29 2019 at 19:19, on Zulip):

hmm

Alexander Regueiro (Aug 29 2019 at 19:19, on Zulip):

how would I get the vtable pointer just from that then?

Alexander Regueiro (Aug 29 2019 at 19:28, on Zulip):

@RalfJ I guess I need to destruct the fat pointer somehow... but how do I get the one for Debug?

RalfJ (Aug 29 2019 at 20:27, on Zulip):

given the type and the trait, there are rustc methods to build a vtable for that

RalfJ (Aug 29 2019 at 20:27, on Zulip):

I think for Miri they are in traits.rs

Alexander Regueiro (Aug 29 2019 at 20:48, on Zulip):

interesting

Alexander Regueiro (Aug 29 2019 at 20:49, on Zulip):

machine.get_vtable -- perfect

Alexander Regueiro (Aug 29 2019 at 21:08, on Zulip):

@RalfJ the use in the unsize_into_ptr method... that's how I'd do it too? for a *const T -> *const dyn Debug cast?

RalfJ (Aug 30 2019 at 07:51, on Zulip):

assuming T: Debug, yes

Alexander Regueiro (Aug 30 2019 at 17:04, on Zulip):

got it, ta.

Alexander Regueiro (Sep 04 2019 at 03:04, on Zulip):

@RalfJ Since my rebase I'm getting no mir for std::rt::lang_start_internal again. I guess this is because the test-miri config option is gone, so I no longer have a sysroot build. I looked at the README, but didn't see anything. What's the right approach presently?

Alexander Regueiro (Sep 04 2019 at 03:08, on Zulip):

obviously this is using a nightly rustc still.

Alexander Regueiro (Sep 04 2019 at 15:25, on Zulip):

@oli maybe you know, too?

Alexander Regueiro (Sep 04 2019 at 17:52, on Zulip):

Eh, don't worry... think I've figured it out.

Alexander Regueiro (Sep 04 2019 at 17:52, on Zulip):

Get a weird stack overflow since the rebase though.

RalfJ (Sep 15 2019 at 13:12, on Zulip):

RalfJ Since my rebase I'm getting no mir for std::rt::lang_start_internal again. I guess this is because the test-miri config option is gone, so I no longer have a sysroot build. I looked at the README, but didn't see anything. What's the right approach presently?

FTR, you have to use xargo to build libstd. cargo miri setup will do it for you.

Alexander Regueiro (Sep 15 2019 at 14:11, on Zulip):

@RalfJ thanks. I had figured that out, but sync the rebase, I'm getting a problem importing the prelude when compiling:
error[E0433]: failed to resolve: unresolved import -- ever encountered this before?

RalfJ (Sep 16 2019 at 10:17, on Zulip):

you might be running into https://github.com/rust-lang/rust/issues/64410 ?

Alexander Regueiro (Sep 16 2019 at 15:41, on Zulip):

hmm, interesting

Alexander Regueiro (Sep 16 2019 at 15:41, on Zulip):

let's see.

Alexander Regueiro (Sep 16 2019 at 16:10, on Zulip):

@RalfJ hmm, seems to be more of a strange issue with not being able to find the sysroot, but I'm not sure

Alexander Regueiro (Sep 16 2019 at 16:10, on Zulip):

I've checked the sysroot is getting built

Alexander Regueiro (Sep 16 2019 at 16:10, on Zulip):

and passed to the compiler correctly

Alexander Regueiro (Sep 16 2019 at 16:11, on Zulip):

miri finds it okay, but not my project

Last update: Nov 17 2019 at 06:55UTC