[haiku-bugs] Re: [Haiku] #8286: Debugger should show the address of stack variables
- From: "anevilyak" <trac@xxxxxxxxxxxx>
- Date: Wed, 18 Jul 2012 12:11:03 -0000
#8286: Debugger should show the address of stack variables
-------------------------------------+----------------------------
Reporter: yourpalal | Owner: anevilyak
Type: enhancement | Status: in-progress
Priority: low | Milestone: Unscheduled
Component: Applications/Debugger | Version: R1/Development
Resolution: | Keywords:
Blocked By: | Blocking:
Has a Patch: 1 | Platform: All
-------------------------------------+----------------------------
Comment (by anevilyak):
Replying to [comment:7 bonefish]:
> Sure, I think it is more likely that one needs the address of a compound
rather than a primitive value, though. And the tool tip still makes it
possible to get the information.
>
Indeed, the more I look at it, the more I like the tooltip approach.
> That reminds me, my original idea for the variables view was to have two
parts: The table view and a details view for the selected variable (mostly
for alternative representation, e.g. for a list the list of members, for a
BMessage a dump, for a BBitmap the bitmap, etc.). That would also be a
good place to show the address.
Just for clarification, was the idea there that the detail view would
occupy the lower half of the variables view or something in that vein?
> Thanks. I like the tool tip version. I would omit the "piece(s)" in the
tool tip and, as mentioned before, use a different visualization of the
address for compound types to avoid confusion with pointer types.
Displaying the address in the "Value" column is purely a visualization
feature. I wouldn't implement that in `CompoundValueNode`.
Will adjust, thanks for the feedback.
> The value subsystem part should be rather simple, at least for equally
sized types (mainly pointers and references). One of the reasons why there
are two node objects -- a `ValueNodeChild` and a `ValueNode` -- to
represent a value object is to support casting. Currently the `ValueNode`
on top of a `ValueNodeChild` is created automatically with the matching
type, but it is possible to explicitly put a `ValueNode` for a different
type on top of it. Obviously for free type conversions a type parser for
the input is required and a way to resolve the respective type.
Understood. As an initial implementation interface-wise, I had thought of
maybe having a drop down list of available types for the user to choose
from, perhaps with some option to type-ahead filter the list, since a
freeform parser would be a bit more complex.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8286#comment:8>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
