From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8575 invoked by alias); 1 Nov 2010 03:40:09 -0000 Received: (qmail 8564 invoked by uid 22791); 1 Nov 2010 03:40:08 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Nov 2010 03:40:02 +0000 Received: (qmail 14286 invoked from network); 1 Nov 2010 03:40:00 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Nov 2010 03:40:00 -0000 Date: Mon, 01 Nov 2010 03:40:00 -0000 From: Daniel Jacobowitz To: Jonathan Larmour Cc: gdb-patches@sourceware.org, Richard Earnshaw , Kazu Hirata Subject: Re: [patch] Add support for ARMv7M devices. Message-ID: <20101101033953.GA15714@caradoc.them.org> Mail-Followup-To: Jonathan Larmour , gdb-patches@sourceware.org, Richard Earnshaw , Kazu Hirata References: <20100609140312.291855664EF@henry1.codesourcery.com> <4C101E0B.4040006@buzzard.freeserve.co.uk> <20100624164149.GD8410@caradoc.them.org> <4C23BA28.80106@buzzard.freeserve.co.uk> <20100816180525.GA13106@caradoc.them.org> <4CCB5CED.4030109@eCosCentric.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CCB5CED.4030109@eCosCentric.com> User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-11/txt/msg00002.txt.bz2 On Sat, Oct 30, 2010 at 12:46:53AM +0100, Jonathan Larmour wrote: > > Jonathan, how's this > > work for you? If your target does not give GDB any registers, then > > this ought to just switch an M-profile binary over to the xpsr. If > > your debug stub previously sends a bogus "cpsr", then it's hard to say > > what will happen. > > I'm not quite sure what you mean by this since the xpsr and cpsr are given > the same register number so I thought that what happens at the remote > protocol level would be the same? The T bit is in a different place. There's at least one existing stub which fakes a "CPSR" register when debugging Cortex-M devices with an XPSR, and moves the T bit to a different place. Are your stubs returning FPA registers and a fake CPSR, or are they returning FPA registers and an XPSR? Both are pretty wonky. > > If it's > > really necessary, we can try to auto-detect that case in the remote > > protocol, but really this is what the XML register descriptions are > > for. > > It does create a problem for me at least because we have existing GDB > stubs implementations programmed into flash on Cortex-M targets (it's hard > to do anything else but program into flash with these small chips). So CVS > GDB (and presumably GDB 7.3+) will no longer work with these > targets. Sure it will. You can override this by providing an appropriate XML file to GDB via set tdesc filename (barring discussion, above, of the T bit). One which matches your stub. Or, you can implement the auto-detection somehow; GDB has infrastructure for that in general, but this case is a bit peculiar. I don't know enough about what your stub returns to say for sure. > I also wonder about any JTAG debuggers which support Cortex-M (e.g. > Ronetix PEEDI). I do not have access to any debugger which supports Cortex-M and the GDB protocol but not XML, sorry. Someone who does needs to figure out what they do. -- Daniel Jacobowitz CodeSourcery