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

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

[Jacob.Bramley at arm dot com]

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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[Jacob.Bramley at arm dot com]

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

Jacob Bramley <Jacob.Bramley at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|https://bugzilla.mozilla.or |
                   |g/show_bug.cgi?id=605758#c6 |
           See Also|                            |https://bugzilla.mozilla.or
                   |                            |g/show_bug.cgi?id=605758

-- 
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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[Jacob.Bramley at arm dot com]

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

Jacob Bramley <Jacob.Bramley at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at sourceware    |Jacob.Bramley at arm dot
                   |dot org                     |com

-- 
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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[pedro at codesourcery dot com]

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

Pedro Alves <pedro at codesourcery dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pedro at codesourcery dot
                   |                            |com

--- Comment #1 from Pedro Alves <pedro at codesourcery dot com> 2010-11-17 10:32:47 UTC ---
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.

-- 
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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[Jacob.Bramley at arm dot com]

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

--- Comment #2 from Jacob Bramley <Jacob.Bramley at arm dot com> 2010-11-17 11:10:35 UTC ---
(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.

-- 
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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[martin at lispworks dot com]

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

--- Comment #3 from martin at lispworks dot com 2012-02-28 17:51:54 UTC ---
Created attachment 6255
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6255
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.

-- 
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.

[Bug tdep/12223] GDB becomes unusable if it fails to speculate about frame information on ARM.

[palves at redhat dot com]

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

--- Comment #4 from Pedro Alves <palves at redhat dot com> 2012-03-06 18:01:57 UTC ---
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!

-- 
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.