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: Alexander Smundak <asmundak at google dot com>
- To: Andy Wingo <wingo at igalia dot com>
- Cc: Doug Evans <dje at google dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Tue, 17 Mar 2015 12:48:00 -0700
- 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>
On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo <firstname.lastname@example.org> wrote:
> On Mon 16 Mar 2015 18:25, Alexander Smundak <email@example.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)
>> return unwind_info
>> return None
> Looks great to me :) Thank you for the consideration!
I realized after writing my proposal that 'create_frame_xxx'
misguides about the type of the returned object. The new
name candidate is `unwind_info_with_id' (omitting 'create'
> 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.
It does not reflect that we are setting previous frame's register.
> 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.
EphemeralFrame emphasizes that the object is short-lived. Maybe it's
better to put forward what this object is for and name it InspectedFrame?
> 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".
'Sniffer' comes from the "GDB Internals" document; I am not too fond of
it, but I thought it's desirable to use similar terminology.
IMHO we reached an agreement on API.
I would really like the reviewers to express their opinions about the naming
at this point. To summarize:
* We need a name for the entity passed to a sniffer. This entity provides
access to the registers of the frame being sniffed, and has factory methods
to create instances returned by a sniffer.
* We need a name for the entity returned by a sniffer.
* Should the term 'sniffer' be used in the API and documentation describing
implementing frame unwinding in GDB extensions?