From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5934 invoked by alias); 6 Jun 2006 03:19:17 -0000 Received: (qmail 5926 invoked by uid 22791); 6 Jun 2006 03:19:17 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 06 Jun 2006 03:19:14 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FnS64-0002rZ-Oj; Mon, 05 Jun 2006 23:19:12 -0400 Date: Tue, 06 Jun 2006 03:19:00 -0000 From: Daniel Jacobowitz To: Steven Johnson Cc: gdb@sourceware.org Subject: Re: GDB support for flash: implementation Message-ID: <20060606031912.GA10922@nevyn.them.org> Mail-Followup-To: Steven Johnson , gdb@sourceware.org References: <20060605210238.GA1036@nevyn.them.org> <20060606005944.GA7504@nevyn.them.org> <4484E26B.3080601@sakuraindustries.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4484E26B.3080601@sakuraindustries.com> User-Agent: Mutt/1.5.11+cvs20060403 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/msg00034.txt.bz2 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. -- Daniel Jacobowitz CodeSourcery