From: Jim Blandy <jimb@codesourcery.com>
To: "Nathan J. Williams" <nathanw@wasabisystems.com>
Cc: gdb@sourceware.org
Subject: Re: GDB support for Flash memory programming
Date: Wed, 24 May 2006 22:17:00 -0000 [thread overview]
Message-ID: <vt24pzfw2c3.fsf@theseus.home.> (raw)
In-Reply-To: <mtumzd8dwn5.fsf@contents-vnder-pressvre.mit.edu> (Nathan J. Williams's message of "23 May 2006 21:44:30 -0400")
"Nathan J. Williams" <nathanw@wasabisystems.com> writes:
> Jim Blandy <jimb@codesourcery.com> writes:
>
>> GDB will have a new write-flash variable. This variable will have
>> three possible states:
>>
>> * on
>> * load
>> * off
>
> How about breakpoints? Should using memory breakpoints require full
> "on" access? (There are some possible optimizations there; the whole
> "step: insert breakpoints, run, remove breakpoints" model is kind of
> bad when the breakpoints are being written to flash).
Flash breakpoints are a challenge. You can use hardware breakpoints,
if available; you can use an MMU and shadow flash pages with RAM
pages, if available; etc.
For the time being, let's assume that GDB will do the best it can with
breakpoints under all settings. Together with the stub, it has enough
information to do as well as can be done.
next prev parent reply other threads:[~2006-05-24 21:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-24 1:44 Jim Blandy
2006-05-24 2:03 ` Steven Johnson
2006-05-24 22:07 ` Jim Blandy
2006-05-25 2:35 ` Steven Johnson
2006-05-24 4:43 ` Nathan J. Williams
2006-05-24 22:17 ` Jim Blandy [this message]
2006-05-24 8:03 ` Russell Shaw
2006-05-25 0:22 ` Jim Blandy
2006-05-25 3:05 ` Russell Shaw
2006-05-25 0:39 ` GDB and remote protocols Daniel Jacobowitz
2006-05-25 3:04 ` Russell Shaw
2006-05-25 0:52 ` GDB support for Flash memory programming Steven Johnson
2006-05-25 1:11 ` Peter Barada
2006-05-25 2:18 ` Jim Blandy
2006-05-25 3:29 ` Steven Johnson
2006-05-26 18:42 ` Jim Blandy
2006-05-27 0:02 ` Steven Johnson
2006-06-17 20:07 ` Mark Kettenis
2006-06-18 9:55 ` Jim Blandy
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=vt24pzfw2c3.fsf@theseus.home. \
--to=jimb@codesourcery.com \
--cc=gdb@sourceware.org \
--cc=nathanw@wasabisystems.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