A similar problem to that described in my previous commit afflicted the
step out case as well. We now store the current IP when issuing a step
out, and use that as the function address once execution returns.
When using step over to step out of a function, we need to use the
address range of the step statement to determine the function which
returned said value, not the current IP, as that has already exited the
function and will consequently be that of the caller, leading to such
returns being attributed to the wrong function, and consequently also
the wrong type.
- Replace use of address + CpuState pair in Thread,
SpecificImageDebugInfo::CreateStackTrace() with a ReturnValueInfoList.
Adjust all implementing subclasses and callers accordingly.
- DwarfImageDebugInfo::CreateReturnValue() -> CreateReturnValues().
Now processes a list of return value information structures rather
than just a single one. This means we can now handle multiple return
values in a single statement. This still isn't entirely correct though,
since, e.g. for functions whose return types fit in a register we need
to either retrieve them immediately after function return, or store the
CPU state at that point in time for later use in value retrieval,
otherwise the return values will all be those of the last called function.
- When we detect that we're stepping over a function call, also store
the CPU state at the time it occurred. This information is needed
in order to correctly reconstruct target addresses later since some
operands may be register-based.
- Add the aforementioned CPU state to CreateFrame()'s arguments and
adjust implementations and callers accordingly.
- ArchitectureX86 now hands off the work for GetInstructionInfo() to
DisassemblerX86, since the latter has all the information we need
to properly classify and evaluate instructions. Correspondingly a
CpuState is passed down to it in order to perform address calculations
for the instruction if it's a jump or call instruction. The latter's
targets are then stored on the thread for later retrieval when
constructing a stack trace. Adjust X86_64 accordingly for the
signature changes. This also fixes a bug where Step Over would
sometimes result in a Step Into instead due to the previous
implementation of GetInstructionInfo() occasionally failing to
classify call instructions correctly.
- Architecture::CreateStackTrace() now takes an argument specifying
the address of the last executed function if applicable. This is used
to decide who/where to decode a return value from. Adjust callers.
- DwarfImageDebugInfo::_CreateReturnValue() uses the above information
in order to know directly who the caller it needs to look up a return
value for is, rather than trying to walk backwards to find them.
Type resolution is now also a bit more sophisticated due to various
cases where the subprogram entry didn't directly contain the return
type but referred to another DIE that did. Retrieving return value
now appears to work properly in all cases except when position
independent code is involved. The latter however will require
resolving the appropriate function address in the PLT, which will
need some additional work.
- Thread now has a data member indicating if a subroutine was
executed during the last set of steps.
- ThreadHandler now sets the aforementioned state appropriate during
Step Over/Step Out.
- Architecture::CreateStackTrace() now takes a parameter indicating
whether return value retrieval is desired (based on aforementioned
thread value). Adjust callers accordingly.
- DwarfImageDebugInfo: If return value retrieval is requested, loop
backwards from the current IP to find the call instruction.
- CreateStackTrace() now takes a parameter indicating whether or not
to try and retrieve full frame information. This in turn is passed
on to SpecificImageDebugInfo, where e.g. DwarfImageDebugInfo can
use it to avoid constructing variables and parameters. This is
used by ThreadHandler since, when it requests the top frame for
its stepping calculations, this additional data/work is completely
unnecessary.