{"id":223,"date":"2013-01-03T18:54:33","date_gmt":"2013-01-03T18:54:33","guid":{"rendered":"http:\/\/blog.mozilla.org\/javascript\/?p=223"},"modified":"2013-01-03T18:54:33","modified_gmt":"2013-01-03T18:54:33","slug":"support-for-debugging-spidermonkey-with-gdb-now-landed","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/javascript\/2013\/01\/03\/support-for-debugging-spidermonkey-with-gdb-now-landed\/","title":{"rendered":"Support for debugging SpiderMonkey with GDB now landed"},"content":{"rendered":"

The main source tree for Firefox, Mozilla Central<\/a>, now includes some code that should make debugging SpiderMonkey with GDB on Linux much more pleasant and productive.<\/p>\n

GDB understands C++ types and values, but naturally it has no idea what the debuggee intends them to represent. As a result, GDB’s attempts to display those values can sometimes be worse than printing nothing at all. For example, here’s how a stock GDB displays a stack frame for a call to js::baseops::SetPropertyHelper<\/code>:<\/p>\n

(gdb) frame
\n#0 js::baseops::SetPropertyHelper (cx=0xc648b0, obj={<js::HandleBase> = {}, ptr = 0x7fffffffc960}, receiver={<js::HandleBase> = {}, ptr = 0x7fffffffc960}, id={<js::HandleBase> = {}, ptr = 0x7fffffffc1e0}, defineHow=4, vp={<js::MutableHandleBase> = {<js::MutableValueOperations<JS::MutableHandle >> = {<js::ValueOperations<JS::MutableHandle >> = {}, }, }, ptr = 0x7fffffffc1f0}, strict=0) at \/home\/jimb\/moz\/dbg\/js\/src\/jsobj.cpp:3593
\n<\/code><\/p>\n

There exist people who can pick through that, but for me it’s just a pile of hexadecimal noise. And yet, if you persevere, what those arguments represent<\/em> is quite simple: in this case, obj<\/code> and receiver<\/code> are both the JavaScript global object; id<\/code> is the identifier \"x\"<\/code>; and vp<\/code> refers to the JavaScript string value \"foo\"<\/code>. This SetPropertyHelper<\/code> call is simply storing \"foo\"<\/code> as the value of the global variable x<\/code>. But it sure is hard to tell—and that’s an annoyance for SpiderMonkey developers.<\/p>\n

As of early December, Mozilla Central includes Python scripts for GDB<\/a> that define custom printers for SpiderMonkey types, so that when GDB comes across a SpiderMonkey type like MutableValueHandle<\/code>, it can print it in a meaningful way. With these changes, GDB displays the stack frame shown above like this:<\/p>\n

(gdb) frame
\n#0 js::baseops::SetPropertyHelper (cx=0xc648b0, obj=(JSObject * const) 0x7ffff151f060 [object global] delegate, receiver=(JSObject * const) 0x7ffff151f060 [object global] delegate, id=$jsid(\"x\"), defineHow=4, vp=$jsval(\"foo\"), strict=0) at \/home\/jimb\/moz\/dbg\/js\/src\/jsobj.cpp:3593
\n<\/code><\/p>\n

Here it’s much easier to see what’s going on. Objects print with their class, like “global” or “Object”; strings print as strings; jsval<\/code> values print as appropriate for their tags; and so on. (The line breaks could still be improved, but that’s GDB for you.)<\/p>\n

Naturally, the pretty-printers work with any command in GDB that displays values: print<\/code>, backtrace<\/code>, display<\/code>, and so on. Each type requires custom Python code to decode it; at present we have pretty-printers for JSObject, JSString, jsval, the various Rooted<\/code> and Handle<\/code> types, and things derived from those. The list will grow.<\/p>\n

GDB picks up the SpiderMonkey support scripts automatically when you’re debugging the JavaScript shell, as directed by the js-gdb.py<\/code> file that the build system places in the same directory as the js<\/code> executable. We haven’t yet made the support scripts load automatically when debugging Firefox, as that’s a much larger audience of developers, and we’d like a chance to shake out bugs before foisting it on everyone.<\/p>\n

Some versions of GDB are patched to trust only auto-load files found in directories you’ve whitelisted; if this is the case for you, GDB will complain, and you’ll need to add a command like the following to your ~\/.gdbinit<\/code> file:<\/p>\n

# Tell GDB to trust auto-load files found under ~\/moz.
\nadd-auto-load-safe-path ~\/moz
\n<\/code><\/p>\n

If you need to see a value in its plain C++ form, with no pretty-printing applied, you can add the \/r<\/code> format modifier to the print<\/code> command:<\/p>\n

(gdb) print vp
\n$1 = $jsval(\"foo\")
\n(gdb) print\/r vp
\n$2 = {
\n  <js::MutableHandleBase> = {
\n    <js::MutableValueOperations<JS::MutableHandle >> = {
\n      <js::ValueOperations<JS::MutableHandle >> = {}, }, },
\n  members of JS::MutableHandle:
\n  ptr = 0x7fffffffc1f0
\n}
\n<\/code><\/p>\n

If you run into troubles with a pretty-printer, please file a bug in Bugzilla<\/a>, under the “Core” product, for the “JavaScript Engine” component. (The pretty-printers have their own unit and regression tests; we do want them to be reliable.) In the mean time, you can disable the pretty-printers with the disable pretty-printer<\/code> command:<\/p>\n

(gdb) disable pretty-printer .* SpiderMonkey
\n12 printers disabled
\n128 of 140 printers enabled
\n<\/code><\/p>\n

For more details, see the GDB support directory’s README file<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":"

The main source tree for Firefox, Mozilla Central, now includes some code that should make debugging SpiderMonkey with GDB on Linux much more pleasant and productive. GDB understands C++ types and values, but naturally it has no idea what the … Continue reading<\/a><\/p>\n","protected":false},"author":543,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/posts\/223"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/users\/543"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/comments?post=223"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/posts\/223\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/media?parent=223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/categories?post=223"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/javascript\/wp-json\/wp\/v2\/tags?post=223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}