Infinite backtrace on (eg.) ARM
Michael Snyder
Michael.Snyder@palmsource.com
Fri Sep 22 01:48:00 GMT 2006
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?"
More information about the Gdb-patches
mailing list