[haiku-bugs] Re: [Haiku] #8286: Debugger should show the address of stack variables
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Wed, 18 Jul 2012 11:05:54 -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 bonefish):
Replying to [comment:5 anevilyak]:
> Replying to [comment:4 bonefish]:
> > I haven't applied and tested the patch, but given how little space
there is for the variables view, a second column might not be the best
solution. Currently the "Value" column is empty for compound types. I
would simply show the address there -- maybe in a slightly different way
(e.g. prefixed with an "@", in parentheses, or with a different font
style) to make clear that it isn't a pointer type. That would cover the
use case mentioned in the description.
>
> That's certainly a possibility. The main reasons I went with a column
were 1) that allows one to see the address for all variables, not just
compounds,
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.
> 2) it's persistently visible unlike a tooltip which makes it more
convenient for comparisons like mentioned in the original feature request,
In the feature request values from two different stack frames need to be
compared, so they can't be seen at the same time either way.
> and 3) the column listview allows one to hide columns one isn't
interested in anyways, so one could simply hide it and revert back to the
2 column view instead if preferred (that would need to be persisted in
settings though, which it isn't yet with this patch).
I find the show/hide column feature nice, but more in the way to be able
to configure your view. The address is something rarely needed, so having
it always shown in the limited space doesn't seems a good setting. And
showing the column temporarily just to get the address seems tedious.
Showing the address in the "Value" column for compounds and having it in
the tool tip for all types seems a reasonable compromise.
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.
> If it makes things easier, I can attach a representative screenshot
later tonight. Another possibility for space reasons would be to simply
default to hiding the column.
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`.
BTW, the cases in
`VariablesView::VariableTableModel::GetToolTipForTablePath()` have
incorrect indentation.
> Casting is also on my TODO list but I need to do a bit more studying of
the value subsystem to be able to implement that one properly.
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.
I don't recall the situation for differently sized types (e.g. int to
double). That might need some explicit support. I think the
pointer/reference casts are more important, though.
--
Ticket URL: <http://dev.haiku-os.org/ticket/8286#comment:7>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
