Design of register/memory viewers

[Vladimir Prus]

Kuba Ober wrote:

>> 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. 

But if the debugger does not reports memory layout at all. You get
continuous view of 4G of memory.

I'm thinking that requiring user to specify the memory region manually might
be the best solution.

- Volodya