Hi,
For those of you hacking nontrivial rust programs presently (say, rustc)
you'll probably want to drop into gdb from time to time. The most useful
thing is being able to get a backtrace. Unfortunately, when we're in a
native call to C there will be a negative previous frame pointer, where
rust jumps from a task stack to the C stack. Gdb by default interprets
this as "stack corruption", so stops unwinding there. Not so useful.
(Go has the same problem, sadly)
A temporary fix for this is to get a modern (trunk "archer") gdb build
with the following patch applied. It just disables the logic for
classifying negative fp jumps as "stack corruption".
We'll keep discussing this with gdb upstream and Go (and anyone else who
has this problem) until it's fixed in a nice general fashion. But our
ABI is likely to shift a bit before it's done. Until then, this patch is
an effective workaround.
-Graydon
diff --git a/gdb/frame.c b/gdb/frame.c
index 53d2fba..88cb47c 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -1496,6 +1496,7 @@ get_prev_frame_1 (struct frame_info *this_frame)
the next frame. This happens when a frame unwind goes backwards.
This check is valid only if this frame and the next frame are NORMAL.
See the comment at frame_id_inner for details. */
+ /*
if (get_frame_type (this_frame) == NORMAL_FRAME
&& this_frame->next->unwind->type == NORMAL_FRAME
&& frame_id_inner (get_frame_arch (this_frame->next), this_id,
@@ -1510,6 +1511,7 @@ get_prev_frame_1 (struct frame_info *this_frame)
this_frame->stop_reason = UNWIND_INNER_ID;
return NULL;
}
+ */
/* Check that this and the next frame are not identical. If they
are, there is most likely a stack cycle. As with the inner-than
_______________________________________________
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
