From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20938 invoked by alias); 24 May 2006 21:16:34 -0000 Received: (qmail 20920 invoked by uid 22791); 24 May 2006 21:16:33 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 24 May 2006 21:16:31 +0000 Received: (qmail 425 invoked from network); 24 May 2006 21:16:29 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 May 2006 21:16:29 -0000 To: "Nathan J. Williams" Cc: gdb@sourceware.org Subject: Re: GDB support for Flash memory programming References: From: Jim Blandy Date: Wed, 24 May 2006 22:17:00 -0000 In-Reply-To: (Nathan J. Williams's message of "23 May 2006 21:44:30 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00355.txt.bz2 "Nathan J. Williams" writes: > Jim Blandy 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.