This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
- From: Andy Wingo <wingo at igalia dot com>
- To: Doug Evans <dje at google dot com>
- Cc: Alexander Smundak <asmundak at google dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 20 Mar 2015 09:26:34 +0100
- Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
- Authentication-results: sourceware.org; auth=none
- References: <CAHQ51u7NUoQ8w9c5mc-Eiz05b1Nub6zqj_Ne7vfgWb5EP9_X8w at mail dot gmail dot com> <21714 dot 40641 dot 510825 dot 30998 at ruffy2 dot mtv dot corp dot google dot com> <CAHQ51u5_ViLaEmv9e43R-wzuWw8dwNkb-2XgCRy5ELQq5FUAWg at mail dot gmail dot com> <54E71694 dot 1080304 at redhat dot com> <CAHQ51u75+9HYAVJXYNQa0gTnQtYKEgmSkyAhAPYp-y4HGtXssg at mail dot gmail dot com> <CAHQ51u6UZ7A47rpGgX0QGeYSTCz1eo_3jWHc=q2ZX3YhqcJ6iQ at mail dot gmail dot com> <87ioei31uj dot fsf at igalia dot com> <CAHQ51u4f+Vx7qXPm-KAAENOceaVogMbDMw6==N_nY+GrLr4Pgg at mail dot gmail dot com> <87d24p19tt dot fsf at igalia dot com> <54FD7DAA dot 7010603 at redhat dot com> <CAHQ51u7sUkGhkmvTaaO_Jo6Jn+kojfiMWHmc2=7OWHThAq6EKw at mail dot gmail dot com> <87twxrncld dot fsf at igalia dot com> <CAHQ51u60nHp1a2DXZ4srvRefyTtge1BUw7-=JuYqChHN_wUGyQ at mail dot gmail dot com> <87ioe1dvu2 dot fsf at igalia dot com> <CAHQ51u7KzQLSLC=QeLA=zd+TUkbbNzzndfeVLFWpjiR-pL8ang at mail dot gmail dot com> <87sid4atms dot fsf at igalia dot com> <CAHQ51u6=9BKf6YSTavbY7u_Mi6miKJ_Yo1QcaG=KsYtYzoWY_Q at mail dot gmail dot com> <CADPb22TW2YC3CLBO9bJGhV7KPM4=mvGoP0AgEd9r8Vd=J0XVxQ at mail dot gmail dot com> <CAHQ51u43Xr3Lc3LT8sQogSuNLaz8cXku3JH0A5LdT=ofvC_PDw at mail dot gmail dot com> <87fv918kyf dot fsf at igalia dot com> <21771 dot 26292 dot 146330 dot 287991 at ruffy2 dot mtv dot corp dot google dot com>
Thanks for taking the time to look at the patches, Doug!
On Fri 20 Mar 2015 01:15, Doug Evans <firstname.lastname@example.org> 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.
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
If we did add a callback interface I don't think there would be a
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
> 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!