This is the mail archive of the gdb-prs@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tdep/12223] New: GDB becomes unusable if it fails to speculateabout frame information on ARM.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]