[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: Design of register/memory viewers
From:       Kuba Ober <kuba () mareimbrium ! org>
Date:       2005-09-01 18:31:06
Message-ID: 200509011431.06781.kuba () mareimbrium ! org
[Download RAW message or body]

On Thursday 01 September 2005 08:26, Vladimir Prus wrote:
> 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? 

Yeah, like this (say on a 16-bit target with no memory in the C000-CFFF 
range):

BFF0 00 00 00 00 00 ....
D000 00 00 00 00 00 ...

> And the biggest problem is that the debugger might not know about 
> memory layout.

Depends on the debugger. If the debugger plugin only supports "contiguous" 
view, then that's what the client gets. If the debugger plugin knows the 
ranges, then you get to see only the ranges.

> > > 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 ;-)

I doubt you have that much mapped in on a typical debugging session. You only 
need to display mapped-in pages. And then I presume it should be selectable 
(again, on plugins that would support it) to display only non-executable 
pages, and so on.

Kuba

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]