This is the mail archive of the
gdb-patches@sourceware.org
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: Alexander Smundak <asmundak at google dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 17 Mar 2015 09:57:31 +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>
On Mon 16 Mar 2015 18:25, Alexander Smundak <asmundak@google.com> writes:
> I'd like to propose one improvement on the Python side: UnwinderInfo
> is constructed by a frame method instead of an implicit constructor.
> I.e., frame.create_frame_with_id(sp, pc) returns UnwindInfo instance
> whose ID is the result of calling GDB's frame_id_build(sp, pc),
> frame.create_frame_with_id_wild(sp) returns UnwindInfo instance
> whose ID is the results of calling frame_id_build_wild(sp), etc.
>
> The example above would then look as follows:
> def unwind(frame):
> if we_can_handle(frame):
> unwind_info = frame.create_frame_with_id(sp, pc)
> unwind_info.set_previous_frame_register("r0", r0)
> unwind_info.set_previous_frame_register(...)
> return unwind_info
> else
> return None
Looks great to me :) Thank you for the consideration!
I might consider naming "set_previous_frame_register" as
"add_saved_register", in anticipation of a possible
add_unavailable_register(), add_unmodified_register(), etc, but that is
just a minor nit.
> As to the class of an object passed to a sniffer, how about calling it
> FrameData? Note that it's not very important from the user's point of
> view as sniffer code does not ever reference it by name.
It's true that from user code it barely matters to Python, but Scheme's
monomorphic flavor makes these things more apparent:
(frame-data-read-register frame "r0")
This doesn't read so well to me -- is it "read-register" on a
"frame-data", or is it "data-read-register" on a "frame" ? A weak point
but "ephemeral-frame-read-register" avoids the question.
I also think that "ephemeral frame" is easier to document as a concept
than the more generic "frame data", and corresponds better to what is
happening in GDB. YMMV, though.
As an aside, it seems to me that if we can avoid it, the word "sniffer"
should not enter the documentation or the API. The Python and Guile
APIs don't just sniff, they do the whole of the unwinding operation, so
it's more clear to call them "unwinders".
Andy