mapping addresses

mapping addresses

[John S. Yates, Jr.]

Looking for advice / guidance:

We are doing a home-grown embedded kernel which
runs with the MMU turned-on.  The twist in this
design is that address maps are true first class
objects that have an existence independent of
any tasks.  A task may have no current map (only
shared regions guaranteed accessible) or it may
explicitly attach to a map.  And of course it is
fully meaningful for a map to exist even though
no tasks are currently attached to it.

For debugging I would like the following:

(1) an address expression syntax that denotes
    dereferencing relative to given map tag

(2) a means of establishing a default map tag
    for those cases where no map tag is given

Is there enough support in GDB for x86 segment
addressing to provide a starting point for (1)?
How generalizable is it?  [Currently using the
PowerPC though in future anything is possible.]

Is current support for switching amount thread
a reasonable starting point for (2)?

tia,

/john


--
John S. Yates, Jr.   508 665-6897 (voice)
Netezza Inc          508 665-6811 (fax)
200 Crossing Blvd.   Framingham, MA 01701

Re: mapping addresses

[Andrew Cagney]

GDB has limited address space support (but it doen't include x86 
segments).  Have a look at:

/* Instruction-space delimited type.  This is for Harvard architectures
    which have separate instruction and data address spaces (and perhaps
    others).

    GDB usually defines a flat address space that is a superset of the
    architecture's two (or more) address spaces, but this is an extension
    of the architecture's model.

    If TYPE_FLAG_INST is set, an object of the corresponding type
    resides in instruction memory, even if its address (in the extended
    flat address space) does not reflect this.

    Similarly, if TYPE_FLAG_DATA is set, then an object of the
    corresponding type resides in the data memory space, even if
    this is not indicated by its (flat address space) address.

    If neither flag is set, the default space for functions / methods
    is instruction space, and for data objects is data memory.  */

#define TYPE_FLAG_CODE_SPACE    (1 << 9)
#define TYPE_CODE_SPACE(t)      (TYPE_INSTANCE_FLAGS (t) & 
TYPE_FLAG_CODE_SPACE)

#define TYPE_FLAG_DATA_SPACE    (1 << 10)
#define TYPE_DATA_SPACE(t)      (TYPE_INSTANCE_FLAGS (t) & 
TYPE_FLAG_DATA_SPACE)

and the discussion thread that lead to it.

enjoy,
Andrew

Re: mapping addresses

[John S. Yates, Jr.]

A week ago it looked like our kernel was heading off
into rather unexplored design space.  Since then we
have simplified things greatly.  We are now planning
a much more traditional scheme in which the kernel
executes in a single flat logical address space.

I am sure that gdb has been used to debug these sorts
of systems many times in the past.  Is there any kind
of support for logical versus physical addressing?

/john

Re: mapping addresses

[Andrew Cagney]

> A week ago it looked like our kernel was heading off
> into rather unexplored design space.  Since then we
> have simplified things greatly.  We are now planning
> a much more traditional scheme in which the kernel
> executes in a single flat logical address space.
> 
> I am sure that gdb has been used to debug these sorts
> of systems many times in the past.  Is there any kind
> of support for logical versus physical addressing?

It's limited.  The d10v talks physical addresses across the remote 
protocol while, internally, GDB still talks logical.

Look for ``translate'' in the d10v code.

Andrew