[webkit-dev] JSCore GDB Integration

[Sanjoy Das]

Hi all!

I've been trying to add GDB support to JavaScriptCore; basically
giving GDB the ability to understand code emitted by the JIT.  This is
easier now, due to a GDB extension I worked on some time back [1].  I
have some of it working, and using a jit-reader plugin (again, see
[1]), it is possible to have GDB display stack traces like the
following (checkTermination and recurse are JS functions):

#0  0x00007ffff662039d in read () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff65c58f8 in _IO_file_underflow ()
   from /lib/x86_64-linux-gnu/libc.so.6
#2  0x00007ffff65c6fde in _IO_default_uflow ()
   from /lib/x86_64-linux-gnu/libc.so.6
#3  0x00007ffff65be60c in getchar () from /lib/x86_64-linux-gnu/libc.so.6
#4  0x000000000040fcf3 in functionReadline (exec=0x7fffb356c308)
    at ../Source/JavaScriptCore/jsc.cpp:358
#5  0x00007fffb416e218 in ?? ()
#6  0x00007fffffffd040 in ?? ()
#7  0x00007fffb416ece8 in checkTermination ()
#8  0x00007fffb416e667 in recurse ()
#9  0x00007fffb416ead1 in checkTermination ()
#10 0x00007fffb416e667 in recurse ()
#11 0x00007fffb416ee28 in checkTermination ()
#12 0x00007fffb416e6be in recurse ()
#13 0x00007fffb416ee28 in checkTermination ()
#14 0x00007fffb416e6be in recurse ()
#15 0x00007fffb416e50e in foo ()
#16 0x00007fffb416e3d2 in ?? ()
#17 0x0000000000b33298 in ?? ()
#18 0x000000000063fb28 in ?? ()


However, I'm having some trouble getting GDB to unwind from the JITted
code into code belonging to the JSCore image.  I suspect this is
because ctiTrampoline does not have debug information.  I tried adding
.cfi directives to the assembly for ctiTrampoline, but that does not
seem to work (I'm yet to figure out why).  In fact, a much easier
solution would be to re-use the jit-reader plugin itself to unwind
through ctiTrampoline.  That can be done easily if I can somehow get
hold of the size (equivalently the PC bounds) for ctiTrampoline.  One
way could be to pad the end of ctiTrampoline with two nops and search
for that pattern in the byte-stream.  But that sounds quite brittle to
me, to be frank.  Is there some other. more robust way to do the same
thing?  Or, perhaps some standard way to completely skip the
ctiTrampoline frame altogether?  This will also be perfectly doable if
I can somehow, by looking at registers and examining some memory,
figure out that a particular frame is the earliest JS frame in the call
stack.

Thanks!

[1]
http://sourceware.org/gdb/current/onlinedocs/gdb/Custom-Debug-Info.html#Custom-Debug-Info
and http://playingwithpointers.com/archives/633
-- 
Sanjoy Das
http://playingwithpointers.com