Opened 8 years ago

Closed 6 years ago

#7761 closed enhancement (fixed)

Debugger return values

Reported by: czeidler Owned by: anevilyak
Priority: normal Milestone:
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

  • showing the return value of the last called function in the variable list would be quite helpful
  • another enhancement would be to add a tooltip on variables in the source view

Attachments (1)

return_values.patch (17.5 KB) - added by anevilyak 7 years ago.
Proof of concept implementation

Download all attachments as: .zip

Change History (7)

comment:1 Changed 7 years ago by anevilyak

Status: newin-progress
Version: R1/alpha3R1/Development

Changed 7 years ago by anevilyak

Attachment: return_values.patch added

Proof of concept implementation

comment:2 Changed 7 years ago by anevilyak

Has a Patch: set

comment:3 Changed 7 years ago by anevilyak

Owner: changed from anevilyak to bonefish
Status: in-progressassigned

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?

comment:4 Changed 7 years ago by anevilyak

Owner: changed from bonefish to anevilyak

A reworked implementation has been checked in with hrev45116. This one doesn't yet handle PLT entries properly though, but appears to work in all other cases for me. Leaving this open until the PLT is handled as well.

comment:5 Changed 7 years ago by anevilyak

Has a Patch: unset

comment:6 Changed 6 years ago by anevilyak

Resolution: fixed
Status: assignedclosed

Barring bugs this should more or less be complete as of hrev45425.

Note: See TracTickets for help on using tickets.