This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Infinite backtrace on (eg.) ARM
- From: Michael Snyder <Michael dot Snyder at palmsource dot com>
- To: GDB Patches ML <gdb-patches at sourceware dot org>, Daniel Jacobowitz <drow at false dot org>
- Date: Thu, 21 Sep 2006 18:48:44 -0700
- Subject: Infinite backtrace on (eg.) ARM
Been thinking about this problem. Check me out here.
Taking a step or two back from the intimate view of gdb internals,
the problem (if I understand it) is detecting the fact that we have
an unusual case of a function that doesn't save it's return address.
We have to detect the fact that we should stop the frame chain at
this function's frame.
So the most common case of a function that doesn't save its return
address is a leaf function, yes? But we can distinguish that case
from the pathological case by looking at the frame->level. A leaf
function can only be at frame level zero, unles we've made a dummy
frame on top of it via a target function call.
So we can check for:
* doesn't save its PC, and
* frame->level > 0, and
* frame->next is not a call dummy.
Except that the information "doesn't save its PC" isn't public
at the point where we want it. It's hidden within frame_register_unwind
and below -- in this case, in trad_frame. So we sort of have a problem
of "what do we know, and when do we know it".
So -- what if we exported a method to make that info public?
It's rather specific, but in this case important: "does this
frame save its return address?"