Error in FrameIterator.py

Error in FrameIterator.py

[Teng Lin]

Hi All,

I run into a problem when exploring new-backtrace command.

(gdb) source -p /opt/archer/share/gdb/python/gdb/command/backtrace.py
(gdb) new-backtrace
Traceback (most recent call last):
   File "/opt/archer/share/gdb/python/gdb/command/backtrace.py", line  
193, in invoke
     for pair in iter:
   File "/opt/archer/share/gdb/python/gdb/FrameIterator.py", line 30,  
in next
     if result == None:
TypeError: Frame object expected in comparison.
Error occurred in Python command: Frame object expected in comparison.


Simply changing "if result == None:" to "if result is None:" can fix  
the problem.

Apparently, the error message is thrown by frapy_richcompare function  
in python-frame.c. Shouldn't frapy_richcompare return Py_RETURN_FALSE.


I have a few other questions for Tom and other Archer developers.

An empty dictionary is always return when fields method from of a type  
is called. Do we actually implement it?
I have preliminary success of translating part of Misc/gdbinit to  
python. One thing I would like to achieve is to print the value of  
certain built-in type, like int, float, string, list, dict and tuple.
Tom, I recall you have a long term to support debugging python or  
other dynamic language  natively in gdb, can you elaborate the idea a  
bit?

Best regards,
Teng

Re: Error in FrameIterator.py

[Tom Tromey]

>>>>> "Teng" == Teng Lin <teng.lin@gmail.com> writes:

Teng> Simply changing "if result == None:" to "if result is None:" can fix
Teng> the problem.

Thanks.

Teng> Apparently, the error message is thrown by frapy_richcompare function
Teng> in python-frame.c. Shouldn't frapy_richcompare return Py_RETURN_FALSE.

Yeah.  I will fix this soon.

Teng> An empty dictionary is always return when fields method from of a type
Teng> is called. Do we actually implement it?

Yes, for struct, union, and class types.
If this doesn't work for you, could you send a small test case?

Teng> I have preliminary success of translating part of Misc/gdbinit to
Teng> python. One thing I would like to achieve is to print the value of
Teng> certain built-in type, like int, float, string, list, dict and tuple.

Cool!

Teng> Tom, I recall you have a long term to support debugging python or
Teng> other dynamic language  natively in gdb, can you elaborate the idea a
Teng> bit?

Sure.  The basic idea is to write enough Python glue so that users can
implement support for a new language entirely in Python.  Then the
next step would be to enhance the UI so that debugging a scripting
language would work as nicely as debugging a compiled language.

There are a few different ways the second task could be done.

E.g., the Python implementation of "backtrace" in the tree shows one
way: replace a CLI command with a Python command and do special things
in Python.  This is not completely ideal (it doesn't work with MI) but
that could be fixed.

Another approach would be to add more language hooks into the gdb C
code.

Yet another idea would be to let Python command implementations call
the original command -- so something like a Python implementation of
"break" could call a Python method in some cases, or call the
underlying C code in other cases.

In some situations it might make sense to just add another command.
E.g., we have "stepi" for instruction-level stepping and "step" for
source-level stepping; maybe we need some third command for
script-level stepping.  (Or maybe not.  It seems to me that users will
want nice ways to switch views between the script code and the
interpreter implementation.  Maybe "set language" suffices.)

Here's a few areas I've identified as needing the scripting treatment.
I probably missed some :)

* "break" and other "decode line" users.
  That is, hook into "break function" so that "function" is
  treated as a name in the scripting language, and then the underlying
  native breakpoints are set appropriately.
* Expression parsing.  Translate an expression in the scripting
  language into a more C-like expression in gdb's internal format,
  suitable for evaluation by gdb's expression evaluator.
* Watchpoints.  Like breakpoints, but harder.
* Frame commands: frame/up/down/backtrace.
  backtrace can already be made to work, as a proof of concept, using
  Python filters.
* Movement commands: step/next/cont/until/return/advance
  (Is that all of them?  I feel like I'm forgetting one.)
  E.g., "step" should implement whatever logic is needed to step a
  single line in the script.

There are also a couple of related features.  One is support for JITs;
it needs some of the above pieces, plus some pieces of its own.
Another is nicer support for languages which are translated to C; this
comes up on irc from time to time.

Anyway, as you can see, this is all rather vague.  I may slowly work
on parts of this but at the moment I don't have a concrete plan for
the whole thing.  I do think it is one interesting direction for the
Python bindings to take; what is really needs is a champion.

Tom