public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
* [Bug tdep/12223] New: GDB becomes unusable if it fails to speculate about frame information on ARM.
@ 2010-11-17 10:09 Jacob.Bramley at arm dot com
  2010-11-17 10:11 ` [Bug tdep/12223] " Jacob.Bramley at arm dot com
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Jacob.Bramley at arm dot com @ 2010-11-17 10:09 UTC (permalink / raw)
  To: gdb-prs

http://sourceware.org/bugzilla/show_bug.cgi?id=12223

           Summary: GDB becomes unusable if it fails to speculate about
                    frame information on ARM.
           Product: gdb
           Version: HEAD
               URL: https://bugzilla.mozilla.org/show_bug.cgi?id=605758#c6
            Status: NEW
          Severity: critical
          Priority: P2
         Component: tdep
        AssignedTo: unassigned@sourceware.org
        ReportedBy: Jacob.Bramley@arm.com
              Host: ARM
            Target: ARM


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

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-03-06 18:02 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-11-17 10:09 [Bug tdep/12223] New: GDB becomes unusable if it fails to speculate about frame information on ARM Jacob.Bramley at arm dot com
2010-11-17 10:11 ` [Bug tdep/12223] " Jacob.Bramley at arm dot com
2010-11-17 10:33 ` Jacob.Bramley at arm dot com
2010-11-17 11:10 ` pedro at codesourcery dot com
2010-11-18  3:43 ` Jacob.Bramley at arm dot com
2012-02-28 17:52 ` martin at lispworks dot com
2012-03-06 18:02 ` palves at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).