Opened 13 years ago
Closed 12 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: | ||
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)
Change History (7)
comment:1 by , 12 years ago
Status: | new → in-progress |
---|---|
Version: | R1/alpha3 → R1/Development |
by , 12 years ago
Attachment: | return_values.patch added |
---|
comment:2 by , 12 years ago
patch: | 0 → 1 |
---|
comment:3 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | in-progress → assigned |
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 by , 12 years ago
Owner: | changed from | to
---|
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 by , 12 years ago
patch: | 1 → 0 |
---|
comment:6 by , 12 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Barring bugs this should more or less be complete as of hrev45425.
Proof of concept implementation