Stream: project-ffi-unwind

Topic: Defining POFs


view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 18:27):

@WG-ffi-unwind I'd appreciate feedback on this new section defining POF: https://github.com/BatmanAoD/project-ffi-unwind/blob/Rfc-POF-terminology/rfcs/0000-c-unwind-abi.md#plain-old-frames

view this post on Zulip acfoltzer (May 28 2020 at 18:33):

I like that a lot. it seems very clear

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 18:39):

Thanks!

view this post on Zulip simulacrum (May 28 2020 at 18:47):

Hm so maybe I misunderstood, but my understanding is that this "Note that a non-POF may become a POF, for instance if all Drop objects are moved out of scope," is maybe too simplistic?

In particular, for something like this:

fn foo(c: bool, v: Droppy) {
    if c {
       std::mem::drop(c);
   }
   call_thing_that_will_try_to_skip_this_frame();
}

I believe we'll currently have a drop flag on the stack and as such the foo function is not POF even though all drop object are out of scope and won't drop

view this post on Zulip simulacrum (May 28 2020 at 18:48):

I don't know the details of why we require POF -- so I'm not sure if the drop flag means UB. But we should be sure to clarify and either link to or include it in the RFC, IMO.

view this post on Zulip simulacrum (May 28 2020 at 18:49):

(in the above Droppy implements Drop, to be clear)

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 19:03):

The intent is to specify frames that can be safely deallocated without executing any drop glue, whether or not drop glue would execute in "normal" unwinding. Deallocation without stopping at landing pads is probably most common with longjmp.

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 19:22):

For the example, it shouldn't be UB if c was true.

view this post on Zulip simulacrum (May 28 2020 at 20:01):

oh, yes, sorry, I meant that c was true in that case -- note that drop glue would get executed in that case

view this post on Zulip simulacrum (May 28 2020 at 20:01):

but that drop glue would look something like if !was_dropped { ... }

view this post on Zulip simulacrum (May 28 2020 at 20:02):

it seems like it should be true that this can be safely skipped, but I am not 100% sure that is always true -- it definitely seems like it relies a good bit on how that's structured exactly

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 20:05):

Perhaps the next step is to ask for confirmation from LLVM devs that skipping the cleanup there (or in an equivalent C++ scenario involving longjmp) is not UB?

view this post on Zulip Amanieu (May 28 2020 at 20:18):

C++ doesn't have drop flags, destructors are always executed.

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 20:28):

Right - so the equivalent scenario would be a destructor that may or may not perform non-trivial cleanup depending on the object's state

view this post on Zulip BatmanAoD (Kyle Strand) (May 28 2020 at 20:29):

E.g., is it UB to unwind over a frame with a unique_ptr after it's been moved-from?

view this post on Zulip Amanieu (May 29 2020 at 10:34):

Technically, yes. (Also I assume you meant longjmp instead of unwind)

view this post on Zulip nikomatsakis (May 29 2020 at 15:16):

I also feel a bit of uncertainty around this question

view this post on Zulip nikomatsakis (May 29 2020 at 15:16):

I suspect it's one of those that almost always works but I'm worried about edge cases

view this post on Zulip BatmanAoD (Kyle Strand) (May 29 2020 at 15:23):

Yes, sorry, I did mean longjmp

view this post on Zulip BatmanAoD (Kyle Strand) (May 29 2020 at 15:25):

I realize it would be undefined according to the ISO C++ standard (due to the way "moved-from" objects are specified), but I'm curious whether LLVM provides stronger guarantees for a specific unique_ptr implementation (since we're not concerned with the specification of the C++ standard lib, but with the safety of skipping "trivial cleanup" operations)

view this post on Zulip Amanieu (May 30 2020 at 02:36):

I'm tending towards allowing this. As long as the destructor is effectively a no-op, we can safely elide it. AFAIK LLVM doesn't perform any code transformations that might invalidate that.


Last updated: Jan 26 2022 at 08:46 UTC