Re: memory region attributes

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Todd" == Todd Whitesel <toddpw@windriver.com> writes:
>> A new data structure would be introduced to describe non-overlapping
>> memory regions.  Each region is defined by the start and end address,
>> and a set of 'attributes' which specify requirements or restrictions
>> of the memory region that GDB must respect.
>> 
>> Attributes I have thought of so far are memory protection (read-write,
>> read-only, or write-only); memory access size (8, 16, 32, or XX bits);
>> whether GDB uses software or hardware breakpoints; and whether GDB can
>> cache reads (dcache).

Todd> One data point I can offer already is that certain 'jumbo' peripherals,
Todd> specifically the VMEchip2 on the motorola mv162 boards, would require a
Todd> small fleet of such memory regions because its register set is made up of
Todd> a mixture of byte and long sized registers, each of which must only be
Todd> accessed with the correct size, or you get a bus error. Fortunately such
Todd> peripherals seem to be rare.

Not rare enough :-).

To handle such beasts with memory regions, I'd create user defined
functions that define regions for the registers of a memory mapped 
device given a base address:

        define def_mem_uglychip
                set $base = $arg0
                mem $base + 0 $base + 3 width=32 ro
                mem $base + 4 $base + 4 width=8
                mem $base + 5 $base + 5 width=8
                mem $base + 6 $base + 7 width=16
                .
                .
                .
        end

and then put them into a library so others wouldn't have to go through
the same pain.

If you have a lot of peripherals with complicated memory maps, it's
going to put a lot of stress on an ordered list representation of
regions.  And regardless of implementation, GDB will have to break
reads and writes into many, many chunks.

        --jtc

-- 
J.T. Conklin
RedBack Networks