#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.