This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?"



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]