This is the mail archive of the
gdb-prs@sourceware.org
mailing list for the GDB project.
[Bug tdep/12223] New: GDB becomes unusable if it fails to speculateabout frame information on ARM.
- From: "Jacob.Bramley at arm dot com" <sourceware-bugzilla at sourceware dot org>
- To: gdb-prs at sourceware dot org
- Date: Wed, 17 Nov 2010 10:09:00 +0000
- Subject: [Bug tdep/12223] New: GDB becomes unusable if it fails to speculateabout frame information on ARM.
- Auto-submitted: auto-generated
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.