[haiku-bugs] Re: [Haiku] #7761: Debugger return values

  • From: "anevilyak" <trac@xxxxxxxxxxxx>
  • Date: Sat, 29 Dec 2012 03:18:14 -0000

#7761: Debugger return values
-------------------------------------+----------------------------
   Reporter:  czeidler               |      Owner:  bonefish
       Type:  enhancement            |     Status:  assigned
   Priority:  normal                 |  Milestone:
  Component:  Applications/Debugger  |    Version:  R1/Development
 Resolution:                         |   Keywords:
 Blocked By:                         |   Blocking:
Has a Patch:  1                      |   Platform:  All
-------------------------------------+----------------------------
Changes (by anevilyak):

 * status:  in-progress => assigned
 * owner:  anevilyak => bonefish


Comment:

 Attached an initial implementation. However, there are a number of issues:

 The current implementation disassembles the function and then looks back
 an instruction to see if it's a function call. If it is, we locate the
 target function and look up its return type (if applicable). However, this
 fails in several cases:
 - On x86, if the return value is 64-bit, this fails to locate the function
 because after the function return two instructions are executed in order
 to copy the return value to its destination variable and consequently we
 don't find the call instruction.
 - Also on x86, for position-independent code the call instruction actually
 jumps into the PLT rather than the function itself. Consequently the
 actual target address of the call isn't the function we want.

 An alternative approach that comes to mind for determining the last
 executed function would be modifying the ThreadHandler to record the
 function address when performing a Step Over/Step Out, and including it in
 the debug event that's generated when we stop execution again after the
 requested step operation. This information would then need to be
 propagated down to CreateStackTrace(), so it can be used within
 SpecificImageDebugInfo::CreateStackFrame(). Such an approach would
 theoretically sidestep all of the above function resolution issues. Would
 that be more reasonable?

-- 
Ticket URL: <http://dev.haiku-os.org/ticket/7761#comment:3>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.

Other related posts: