enhanced gdbinit file - looking for Python+Emacs+gdb users

I got a little carried away with the gdbinit file that lives in the Python distribution at Misc/gdbinit today. I decided there's no particular reason that gdb shouldn't display the current Python file when moving up and down the C stack any time it encounters PyEval_EvalFrame. After a little digging I realized this would be pretty easy. I made two changes to the gdbinit file: 1. I wrote a lineno command for gdb that calculates and prints the current Python line number. (It's PyCode_Addr2Line written in gdb's command language.) 2. Using that and the current file gleaned from PyEval_EvalFrame I emit the file:line info in the correct format for Emacs to display the Python line number at the right time using overridden up and down commands. There's one slight hitch. It works perfectly when travelling up the C stack using the up command, however in my environment at least (MacOSX w/ Apple's gcc and gdb) it causes gdb to segfault when travelling down the stack. I can't see anything that would make the behavior different going up instead of down. I need some people to try this thing out to see if it barfs for them as well. Maybe it's just something peculiar to my environment. OTOH, perhaps it's a bug in gdb. Since I can't really check this beast in given its current rather dicey behavior, I dropped a copy at http://www.musi-cal.com/~skip/python/gdbinit If you use Python with gdb via Emacs please give it a whirl and let me know how it works for you. Thanks, Skip P.S. I think I know how to make the gdb print command print Python objects as well...

Skip Montanaro wrote:
There's one slight hitch. It works perfectly when travelling up the C stack using the up command, however in my environment at least (MacOSX w/ Apple's gcc and gdb) it causes gdb to segfault when travelling down the stack. I can't see anything that would make the behavior different going up instead of down. I need some people to try this thing out to see if it barfs for them as well. Maybe it's just something peculiar to my environment. OTOH, perhaps it's a bug in gdb.
Without actually looking at your code: a segfault in gdb is always a bug, even if triggered through gdb macros. Regards, Martin
participants (2)
-
"Martin v. Löwis"
-
Skip Montanaro