public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Chris Faylor <cgf@cygnus.com>
To: "J.T. Conklin" <jtc@redback.com>
Cc: gdb@sources.redhat.com
Subject: Re: wince, dcache, and memory region attributes
Date: Mon, 13 Nov 2000 13:36:00 -0000	[thread overview]
Message-ID: <20001113163559.A9623@redhat.com> (raw)
In-Reply-To: <5msnov4nnm.fsf@jtc.redback.com>

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

      reply	other threads:[~2000-11-13 13:36 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-13 12:34 J.T. Conklin
2000-11-13 13:36 ` Chris Faylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20001113163559.A9623@redhat.com \
    --to=cgf@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=jtc@redback.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).