Like many people who have overdosed on syntax highlighting and other forms of colorization, my brain is no longer able to process monochrome text displays. Which is why I have been so excited about gdb with python crammed inside. (The good sense of “crammed”, wherein one is cramming cookies in one’s mouth.) I have perverted its spirit and used it to colorize gdb backtraces! Woo!
While I was in there, I have done two useful things:
- There is magic of limited potency that normalizes the path automatically.
- It looks at all the values in the arguments (and locals too, I guess) and if they are used more than once, it considers making them “interesting”. Interesting values get named based on where we first saw them, and assigned a color. Then, whenever they appear in the backtrace, they get their special name and color to help us see the flow of values through the backtrace. For example, in the screenshot above you can see “this5” in a nice* blue color. Each time its value appears, the “this5” label appears (the 5 is for frame 5). I find this easier than manually scanning using my brain.
My hg repo is here: http://hg.mozilla.org/users/bugmail_asutherland.org/pythongdb-gaudy/
If you like this, or if you don’t like this but do like useful things, you are even more likely to like Jim Blandy’s archer-mozilla repo which is full of magic debugging help for spidermonkey in gdb. (nb: The python-gdb trunk right now has changed how pretty printers register, and I don’t think that repo has yet caught up.) Also, see Tom Tromey’s blog posts about the whole python-gdb thing.
* When I use “nice” in terms of colors, this is from my perspective as someone who demands many colors, has the time to add crazy colors to everything, but inexplicably does not have the time to actually pick colors that humans find appealing (or even non-nauseating). I am going to pass the buck to the people who originally conceived of 256-color xterms and thought I could be trusted with a color cube, no matter how limited.
WoW!
That is so awesome, i have dreamed of such a thing for months 🙂
The problem is, that I don’t use gdb so often to be sure, if i’ll take the work needed to set that up, but it’s really great! I wished gdb supported an –color option, as it’s really impossible to grep monochrome text quickly 🙁
PS: If somebody would just do the same to “apt” – i find it impossible to use apt as quickly as gentoo’s good old emerge, as it lacks colors.
This is an awesome feature! I’d like to encourage you to post your script to the Archer mailing list, or even GDB mailing list itself (even though I’m sure your patch uses bits from the Python support which are not integrated upstream yet). It’d be really nice to be able to ship a coloured backtrace in GDB and Archer!
PS1: We are still sorting out how to actually ship Python code in an official GDB release, so that may not happen before 7.0 goes out.
PS2: I don’t think we’ll be able to merge upstream everything you need to implement a backtrace command in Python, so it’s not likely your script would work/ship with GDB 7.0, but most certainly would with GDB 7.1. But who knows, perhaps we can merge all the dependencies in time for 7.0… I’ll certainly try to do that.
PS3: Tom Tromey also saw this, and he suggested that a coloured backtrace could be implemented a little bit differently, so you may expect some rework before your code would enter the Archer branch and GDB upstream…
Thanks, Thiago.
I definitely believe this could be implemented differently… it would be horrible if colorized versions of commands always ended up being hacked up variants of the base command with colorization added in.
Of course, my differently would probably be a wildly over-engineered approach where everything is emitted to a stream as a type, which by default just does a simple str(). The colorizing output would look at the types as they went by and wrap the str() in the color assigned to the item. This would allow for UI’s where the semantic information is not lost on display, allowing useful right-click info, etc.
The problem with that approach, in my mind, is that it seems contrary to the existing pretty-printer mechanism. I’d expect Tom Tromey’s solution is probably far more pragmatic and likely to be adopted 🙂
Pingback: visophyte: data made shiny :: gaudily syntax-highlighted code listings in (archer) gdb