Where frame debug information is not available, such as when executing some JIT-compiled code in Mozilla's Trace Monkey, GDB tries to guess what the frame looks like by assuming that the 'FP' register points to a traditional frame. Most JIT-compilers don't actually use a traditional frame, so this generally fails, and no frame information can be found. Provided that the FP points to a valid memory address and it looks enough like a frame that GDB can attempt to read it, everything works fine. No, you don't get backtraces, but you can still do instruction-level debugging. By some amazing coincidence, at least Trace Monkey has had this property until recently. Trace Monkey now stores a value at *fp which is not a valid pointer, and GDB falls over. When JIT-compiled code is stepped into, GDB dumps the following to the terminal: (gdb) si Cannot access memory at address 0x5ffff8 (The memory address depends on the value at *fp.) Any further commands (including 'quit') result in a repeat of the message, and the debug session is essentially lost. ---- The fix for this requires a modification of the logic in arm_scan_prologue as follows: • Detect memory access errors in frame speculation and bail out cleanly. • Use memory access functions which don't print to the terminal if an error is detected. (Otherwise, even if the speculation fails cleanly, the user still sees an error message after every command in the JIT-compiled code.) Instruction-level debug is once again possible with these changes. ---- Refer here for my original description of the problem: https://bugzilla.mozilla.org/show_bug.cgi?id=605758#c6
This does not invalidate your report in any way, but I'd just like to point out GDB's JIT compiler interface which Trace Monkey could use to provide GDB with debug info for the JIT compiled code. See: <http://sourceware.org/gdb/download/onlinedocs/gdb.html#JIT-Interface> You may well be aware of it, but, there it goes for the archives.
(In reply to comment #1) > <http://sourceware.org/gdb/download/onlinedocs/gdb.html#JIT-Interface> Oh I agree, it would be nice if we could use the JIT interface. If nothing else, it would presumably give us back-trace information through JIT frames, and that could be useful at times. However, integrating it into Trace Monkey is a rather more fiddly task than fixing GDB, and it doesn't scale when we start looking at more than a handful of JIT compilers, so I'd like to fix the problem in GDB first.
Created attachment 6255 [details] patch to handle memory access errors I've been having the same problem here in a situation where r11 isn't the frame pointer and the attached patch has been working well for me.
read_memory is just a wrapper for target_read_memory that throws MEMORY_ERROR on access errors. So instead of further wrapping read_memory in try/catch, the right thing to do is to use target_read_memory (+extract_(un)signed_integer) directly, thus avoiding the exception to begin with. Please do read through CONTRIBUTE linked from <http://sourceware.org/gdb/contribute/>. Thanks!