Conditional breakpoints in ceval.c
demianbrecht at gmail.com
Tue Nov 12 16:40:26 CET 2013
On Sat, Nov 9, 2013 at 5:33 AM, <python-list-request at python.org> wrote:
> I don't know how to use gdb the way you want, but it sounds like you are on a fascinating journey of discovery. What are you trying to learn? Perhaps we can talk about how the interpreter works.
Apologies for not getting to this sooner, I took a much needed short
hiatus from touching all things computers over the long weekend.
A little backstory to how I got to this sticking point:
I decided to write a series of blog posts about the lesser-known areas
of the Python stdlib (I was considering doing a lightning talk about
one or two of them). First stop was abc's. When digging into that, I
realized that the implementation of abcs is a bit different than other
modules in the stdlib: It's only partially implemented in Python.
After digging into that more and figuring out how that was all
implemented in C, I also found that, while I understood how to use
metaclasses, I didn't quite understand how the interpreter used
metaclasses to build new classes (I had read the docs, but felt that I
couldn't explain it to my grandmother and therefore, a blog post on
metaclasses likely would only be surface level and wouldn't include
any information outside of what's readily available through the docs).
At that point, I had spent quite a bit of time grep'ing and grok'ing
various parts of the interpreter code. I felt there /had/ to be a be a
more efficient way to see what's going on for a particular code block.
Further digging pointed me to compile/dis to get the bytecode
generated by code blocks. This then led me to ceval.c, setting
breakpoints to step through and see what actually happens with the
code. This is where I ran into a bit of a wall due to my lack of
practice with gdb.
What I'm trying to do is essentially figure out a way to break into
the interpreter code at arbitrary points in my Python code so I can
step through exactly what's going on (which would be tremendously
useful IMO). I think what I lack is a fundamental understanding of how
to access attributes of the various Python object types at the
interpreter level. For example, if I want to break on the assignment
"foo = 'bar'", then I want to look for something to the effect of
(int)(strcmp(*(PyTuple_GetItem((consts), (oparg))->[??]), "bar") == 0.
As an aside, this has definitely been one of the more interesting digs
that I've taken at Python and has been quite enjoyable and fulfilling
(my /god/ I'm a nerd ;)). You never /can/ really push the boundaries
with your tools without wholly understanding them.
More information about the Python-list