[prev in list] [next in list] [prev in thread] [next in thread]
List: haiku-bugs
Subject: [haiku-bugs] Re: [Haiku] #7761: Debugger return values
From: "anevilyak" <trac () haiku-os ! org>
Date: 2012-12-29 3:18:14
Message-ID: 058.3953dd9f828949d153458a2a98447119 () haiku-os ! org
[Download RAW message or body]
#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.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic