[prev in list] [next in list] [prev in thread] [next in thread]
List: kdevelop
Subject: Re: Design of register/memory viewers
From: Vladimir Prus <ghost () cs ! msu ! su>
Date: 2005-09-01 6:40:03
Message-ID: 200509011040.03529.ghost () cs ! msu ! su
[Download RAW message or body]
On Wednesday 31 August 2005 21:55, Gunther Piez wrote:
> > For register view, I have two alternatives:
> > 1. Create another window (near the "variables" view), that would \
> > display registers
> > 2. Show registers in the "variables" view -- add new top-level item, \
> > and make register children of that item.
>
> I would prefer the second way... You probably know you can add registers \
> in the watch window via typing $eax or $rax,
Yea, although KDevelop will show it as pointer, and if you even try to \
click on "+" near $eax things will stop working for me.
> but you have to retype it every
> time you start the debugging frontend.
> Another point would be a configurable font for at least the watches, \
> since the standard font may be to big for a lot of register/variables.
OTOH, you can close "locals" and "watches" items when you're debugging
assembler code.
> And if it comes to asm debugging, it would be nice to have configurable
> types for the registers, for example on x86 or amd64 a xmm register might
> hold a v4sf, a v2df or a v16qi or something. But ok, this is a nice to \
> have :-)
This can come for free: xmm1 will have several subitems for possible \
content types and each subitems will have proper number of children with \
values. That will come almost for free.
> > For memory, I can think only about creating another window. It can have
> > "start/end" input boxes just like current memory viewer, or it can have
> > tabs, allowing to view several memory regions at the same time.
>
> If somebody wants to watch more than one memory region, wouldn't it be
> possible for him to use just another view?
If that's a tool window docked to the left side, then you can have only \
one.
> More important in my eyes is a configurable type for a memory element. \
> The obvious choice is a byte, shown in hexadecimal, but if it possible to
> diplay it in decimal or binary it would be nice. Also, the base type is
> often something different than a byte, and int or a long seems quite
> common.
So, that would make 8bit/16bit/32bit/64bits size options and
hex/binary/decimal as format.
> The optimum would let me use a type defined in my program and even
> let me specify the stride and the amount per line...
Can you explain? The amount per line should ideally depend on window width.
> And yes, a configurable font size comes in handy when displayng huge
> amounts of data... :-)
Noted.
- Volodya
-
to unsubscribe from this list send an email to \
kdevelop-request@kdevelop.org with the following body: unsubscribe \
»your-email-address«
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic