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

[Alexander Smundak <asmundak@google.com>]

On Tue, Mar 17, 2015 at 1:57 AM, Andy Wingo <wingo@igalia.com> wrote:
> 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 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'
prefix, too).

> 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?