memory region attributes
J.T. Conklin
jtc@redback.com
Tue Oct 26 17:42:00 GMT 1999
>>>>> "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
More information about the Gdb
mailing list