Re: [PATCH 05/10] gdb/python: add some additional methods to gdb.PendingFrame

[Andrew Burgess <aburgess@redhat.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Andrew Burgess <aburgess@redhat.com>
>> Date: Fri, 10 Mar 2023 14:55:22 +0000
>> From: Andrew Burgess via Gdb-patches <gdb-patches@sourceware.org>
>> 
>>  gdb/NEWS                               |  20 +++
>>  gdb/doc/python.texi                    |  40 +++++
>>  gdb/python/py-unwind.c                 | 221 +++++++++++++++++++++++++
>>  gdb/testsuite/gdb.python/py-unwind.exp |  33 +++-
>>  gdb/testsuite/gdb.python/py-unwind.py  | 104 ++++++++++++
>>  5 files changed, 417 insertions(+), 1 deletion(-)
>
> Thanks.
>
>> diff --git a/gdb/NEWS b/gdb/NEWS
>> index ed0f86e79ec..0d9049ff134 100644
>> --- a/gdb/NEWS
>> +++ b/gdb/NEWS
>> @@ -110,6 +110,26 @@ show always-read-ctf
>>       without the particular unwinder, depending on how 'enabled' was
>>       changed.
>>  
>> +  ** New methods added to the gdb.PendingFrame class.  These methods
>> +     have the same behaviour as the corresponding methods on
>> +     gdb.Frame.  The new methods are:
>> +
>> +     - gdb.PendingFrame.name(): Return the name for the frame's
>> +       function, or None.
>> +     - gdb.PendingFrame.is_valid(): Return True if the pending frame
>> +       object is valid.
>> +     - gdb.PendingFrame.pc(): Return the $pc register value for this
>> +       frame.
>> +     - gdb.PendingFrame.language(): Return a string containing the
>> +       language for this frame, or None.
>
> "containing the language"?  I think this is better:
>
>   Return the language of this frame, as a string, or None.

Changed to use your wording.

>
>> +     - gdb.PendingFrame.find_sal(): Return a gdb.Symtab_and_line
>> +       object for the current location within the pending frame, or
>> +       None.
>> +     - gdb.PendingFrame.block(): Return a gdb.Block for the current
>> +       pending frame, or None.
>> +     - gdb.PendingFrame.function(): Return a gdb.Symbol for the
>> +       current pending frame, or None.
>
> Btw, why do you follow each method name with a "()"?  That looks like
> a call with no arguments, which is not what you mean, right?

I did indeed mean a call with no arguments.  These would be used like
this:

  class TestUnwinder(Unwinder):
      def __init__(self):
          super().__init__("Unwinder_Name")
  
      def __call__(self, pending_frame):
          is_valid = pending_frame.is_valid()
          name = pending_frame.name()
          pc = pending_frame.pc()
          language = pending_frame.language()
          sal = pending_frame.find_sal()
          block = pending_frame.block()
          function = pending_frame.function()

Maybe you thought these would be better implemented as attributes?  If
you did then I 100% agree, but I think these have to be methods in order
to match the existing Frame API.  If we use the same API for
PendingFrame and Frame then a user can write code that will work on
either object type.

Does this address your concerns?  Or did I not understand?

Thanks,
Andrew