wince, dcache, and memory region attributes

wince, dcache, and memory region attributes

[J.T. Conklin]

The dcache is usually disabled when GDB starts, but the wince target
enables it with a call to set_dcache_state(1).

I am trying to get a bit of backround about why the wince target does
this.  In my experience with other embedded systems/OSs, a GDB user
generally wouldn't want GDB caching memory because of memory mapped
I/O devices.  Is there something about Win-CE or the typical Win-CE
developer that is different?

The reason I ask is that after the memory region attribute code is
committed, a GDB user will be able to define regions of memory and
specify the cache / nocache attribute separately for each one.  But
when a user does not define regions, or accesses are made to memory
that is not within a defined region, the "default" set of attributes
are used.  At present, the default attributes has the nocache set.  

Will this make things difficult for Win-CE users?  I'd rather not 
provide knobs that change the default memory attributes depending on
what targets are linked into GDB.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Re: wince, dcache, and memory region attributes

[Chris Faylor]

Hi,

On Mon, Nov 13, 2000 at 12:34:05PM -0800, J.T. Conklin wrote:
>The dcache is usually disabled when GDB starts, but the wince target
>enables it with a call to set_dcache_state(1).
>
>I am trying to get a bit of backround about why the wince target does
>this.  In my experience with other embedded systems/OSs, a GDB user
>generally wouldn't want GDB caching memory because of memory mapped
>I/O devices.  Is there something about Win-CE or the typical Win-CE
>developer that is different?

It was primarily for speed considerations.  It can be turned off
without affect functionality, obviously.

Windows CE is essentially a stripped down version of Windows.  My port
of gdb to use a Windows CE device just allows you to debug applications
on the device.  It doesn't allow debugging of the OS itself where
considerations like memory mapped I/O might be an issue.

However, memory mapped file I/O is available to Windows CE applications,
so maybe there is an issue there.  I have no idea how common it would
be to use this on Windows CE.

>The reason I ask is that after the memory region attribute code is
>committed, a GDB user will be able to define regions of memory and
>specify the cache / nocache attribute separately for each one.  But
>when a user does not define regions, or accesses are made to memory
>that is not within a defined region, the "default" set of attributes
>are used.  At present, the default attributes has the nocache set.  
>
>Will this make things difficult for Win-CE users?  I'd rather not 
>provide knobs that change the default memory attributes depending on
>what targets are linked into GDB.

I just turned on caching to ameliorate the inordinate lag engendered
when communicating with a Windows CE device using Microsoft's protocols.
There are optimizations that could be made to the way that gdb communicates
with the hand-held device that could speed things up.  So, if it isn't
possible to keep things the way they are now, then turning off caching
will only have a minor, correctable effect.  I can offer many helpful
suggestions to anyone who wants to speed things up. :-)

I'm actually not aware of anyone actually using gdb to debug Windows CE
applications.  It would be sort of interesting to see if they started
showing up here, complaining, if things slowed down...

So, please just do whatever makes sense for gdb and don't worry about
Windows CE.

cgf