memory region attributes
J.T. Conklin
jtc@redback.com
Tue Oct 26 15:52:00 GMT 1999
One of the more frustrating things about using GDB on an embedded
system is that it uses software breakpoints for internal breakpoints
(bp_until, bp_finish, bp_step_resume, etc.) even through the program
may be executing out of some type of read-only memory. Another is
that there is no way to specify the size of reads and writes, which is
often necessary when accessing registers of memory mapped I/O devices.
These can be worked around, but I believe enhancing GDB will result in
a superior solution.
Here is my proposal for addressing this problem. Comments are welcome.
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).
I haven't spent too much time thinking about implementation details,
other than that in most cases, users will only define a small number
of regions, so a ordered linked list (of memory regions) is probably
adequate. If this turns out not to be the case, it should not be
difficult to use a tree of some type.
If I haven't spent time on implementation details, I've spent even
less thinking about the user interface.
Synopsis:
(gdb) mem <start address> <end_address> [attribute ...]
Attributes:
rw - memory is read/write (default)
ro - memory is read only, GDB will refuse to issue a write
command.
wo - memory is write only, GDB will refuse to issue a read
command.
8,16,32 - access memory in X sized operations
hwbreak - GDB internal breakpoints use hw breakpoints
swbreak - GDB internal breakpoints use sw breakpoints (default)
cache - enable host-side caching
nocache - disable host-side caching (default)
Examples:
(gdb) mem &start &etext ro cache
(gdb) mem &uart_base &uart_base + 0x0f 8
Things I haven't thought through yet:
+ How are memory regions identified? By start/end addresses? By
number like breakpoints?
+ How do you remove memory regions? How do you change the attributes
of existing regions?
Thoughts, anyone?
--jtc
--
J.T. Conklin
RedBack Networks
More information about the Gdb
mailing list