From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10187 invoked by alias); 6 Jun 2006 06:16:46 -0000 Received: (qmail 10178 invoked by uid 22791); 6 Jun 2006 06:16:45 -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; Tue, 06 Jun 2006 06:16:44 +0000 Received: (qmail 19673 invoked from network); 6 Jun 2006 06:16:41 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 6 Jun 2006 06:16:41 -0000 To: Steven Johnson Cc: gdb@sourceware.org Subject: Re: GDB support for flash: implementation References: <20060605210238.GA1036@nevyn.them.org> <20060606005944.GA7504@nevyn.them.org> <4484E26B.3080601@sakuraindustries.com> <20060606031912.GA10922@nevyn.them.org> From: Jim Blandy Date: Tue, 06 Jun 2006 06:16:00 -0000 In-Reply-To: <20060606031912.GA10922@nevyn.them.org> (Daniel Jacobowitz's message of "Mon, 5 Jun 2006 23:19:12 -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-06/txt/msg00035.txt.bz2 Daniel Jacobowitz writes: > On Tue, Jun 06, 2006 at 01:03:23PM +1100, Steven Johnson wrote: >> A problem I see with this, is targets where the memory map changes on >> the fly, for example, my ARM target starts with Flash mapped at address >> 0x0, for 512K (for booting). Some time later, flash is remapped to >> another address, say 0x40000000 for 512K and some SRAM is mapped down to >> 0x0 for 16K. If GDB thought Flash was still at 0x0 after this it would >> be wrong, and "The target HAS come along and surprised us later". There >> would need to be some mechanism for the stub to say "Things changed, >> reinitialise". How a stub would detect this or tell GDB about it, is >> another issue, but at least GDB needs to be able to re-sync when a >> target changes its memory arrangement in any significant way. >> >> This is one reason why i preferred a "map" style command, so that if >> things like this changed, the person doing the debug could force the >> necessary changes onto GDB's understanding of the target, if required. >> I don't mind the "automatic" retrieval of info from a stub, but it >> should be able to be over-ridden if required. > > Good point. I'm going to have to think about this. I don't really > want to give up on the idea, but it may need a little work. > > Jim, this may be a persuasive argument in favor of separating the > memory map from the features, as you were talking about earlier. > I still don't like the idea, but my current mental model isn't wired > for virtual memory. Wow. I hadn't thought about that at all. It seems like the stub should be able to check the affected memory type before it does each write. And if the stub can produce errors reliably in response to attempts to write the wrong sort of memory (X and M to flash, vFlashWrite to non-flash), then GDB would know it needed to refresh its map. Certainly if we've got a map, there need to be user mechanisms for viewing it and correcting it.