Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python

[Andy Wingo <wingo at igalia dot com>]

Hi,

Thanks for taking the time to look at the patches, Doug!

On Fri 20 Mar 2015 01:15, Doug Evans <dje@google.com> writes:

> 2) IIUC, setting aside hitting the outermost frame and such,
> it's a rule that some unwinder will recognize the frame.
> Therefore "ephemeral" isn't quite right, even "real"
> frames are ephemeral since we toss the frame cache when
> the inferior resumes. OTOH, we need to make progress
> and I'm just throwing this out there. "ephemeral" is
> fine with me: we don't use that term for anything else
> which is nice.

Just to throw out some other names -- PendingFrame.  Alexander mentioned
InspectedFrame.  IntermediateFrame.  FrameTemplate.  SkeletonFrame.
MinimalFrame.  FrameStub.

Dunno, just some ideas :)

> 3) We need to allow sniffers to record anything they
> want in gdb.UnwindInfo/<gdb:unwind-info>.

I see from your point (4) later that you are thinking that if we add
some kind of callback interface to UnwindInfo that e.g. Guile code might
need to fetch arbitrary data from the UnwindInfo.

You also note correctly that this is not currently something that the
patches require -- the UnwindInfo contains all of the information, and
the C prev_register/this_id callbacks just look into the UnwindInfo
data.

If we did add a callback interface I don't think there would be a
problem.

Let's say we want to add a way for prev_register to call back into
Guile.  If the prev-register callback is added to the unwind info via
unwind-info-set-prev-register-callback! or something then the callback
can be a closure that captures the data it needs.  Or it can use an
external weak hash table.  Or when we add the
set-prev-register-callback! interface, we can add some other associated
interface to store data in the unwind-info.  There are multiple fine
options here.

> 5) The docs don't make any mention of target endianness
> in the saved register values. They probably should.

+1 to Alexander's answer -- as they are GDB values, there shouldn't be
an issue, should there?

> 6) I noticed several routines for building frame ids in Python.
> Both Python and Guile support keyword based arguments to functions.
> Can we just have one frame id builder function and each take
> sp and pc (and special if we need to) as keyword arguments?
> E.g. (make-unwind-info ephem-frame #:sp sp #:pc pc)
> But see (7) below.
>
> 7) If we ever need to use frame ids in the extension language
> IWBN if they were their own object, in which case we might have
> (make-unwind-info ephem-frame #:frame-id frame-id)

This would be fine; and actually at this point the kwarg is unnecessary.

  (make-unwind-info ephem-frame frame-id)

> but then I'm wondering if there should be an
> unwind-info-set-frame-id! function and move sp,pc there.

I agree with Alexander that this isn't great.  The only thing that an
unwinder *must* do is set a frame ID.  It must produce a frame_id at the
same time as the sniffer returns TRUE.  (They are different callbacks
but always called one after the other.)  Therefore it makes sense to
have the invariant:

  Is it an UnwindInfo?  Then it definitely has a frame ID.

That way it takes away one possible error case.  Also you wouldn't want
to set the frame ID on an UnwindInfo twice, it doesn't make sense.

> I'm not sure where to put the UnwindInfo creator (factory method).
> Do we need one?  Can we just create them via normal object construction?

In Guile you have to give it a name of course -- make-unwind-info.  But
in Python I liked Alexander's use of a factory method.  But I dunno,
I'll leave the Python discussion to you all :)

> 8) Re: set_previous_frame_register vs unwind-info-add-saved-register!
>
> Dunno. On this particular point I guess I don't have a strong
> enough interesting in being consistent.
> I'll let you guys decide.

If you don't have such an interest on being consistent for this piece
then I guess the easy way is to leave these as they are then.  Avoids
multiple-day awkward backs and forths :)  But if you decide they need to
be the same let us know.

Speaking for myself I prefer the Guile one of course, but I prefer
executive decisions over having to endure more days of naming
discussions over email :)

Thank you again Doug for the time!

Andy