Design of register/memory viewers

Vladimir Prus ghost at cs.msu.su
Thu Sep 1 14:27:22 UTC 2005


On Thursday 01 September 2005 16:14, Kuba Ober wrote:
> On Thursday 01 September 2005 02:40, Vladimir Prus wrote:
> > On Wednesday 31 August 2005 20:04, Kuba Ober wrote:
> > > For memory viewers, it'd be nice to be able to select (morph) a viewer
> > > to: - display whole memory of a process, with starting address being
> > > adjustable by typing a new value in the input box + scroll of course
> > > would work
> >
> > That's tricky. How do you get "whole memory of process". The use case I
> > have here is DSP processor with 3 memory ranges -- one at 0x00000000,
> > another at 0x80000000 and yet another at 0xC0000000. So there's no single
> > continuous region of memory.
>
> Which is fine. I didn't say it has to be contiguous ;)

Ah.. and so will you get while scrolling? Immediate jump to next memory block?
And the biggest problem is that the debugger might not know about memory 
layout.

> > And some of those memory ranges is 64M --
> > might be not so good to show that much.  And for orginary PC, memory
> > range can be even larger.
>
> Fine too. You don't have (and even can't -- would be impractical) to
> display all of it. Only the visible stuff should be queried from the
> debugger and then displayed. Some targets have horrible memory dump speeds
> when debugging (Z8 Encore! comes to mind) so it's not feasible to even ask
> the debugger for all of it if it's not needed. This needs to be
> interactively querying the debugger whenever you scroll/change address. I
> see no other way.

That's for sure. But if you display 4G of memory (even lazyly), that would 
make scrollbar completely useless. One pixel will correspond to too many 
bytes of memory ;-)

- Volodya




More information about the KDevelop-devel mailing list