This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

memory region attributes


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]