From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 870 invoked by alias); 29 Oct 2010 23:47:10 -0000 Received: (qmail 861 invoked by uid 22791); 29 Oct 2010 23:47:09 -0000 X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 tests=AWL,BAYES_20,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 29 Oct 2010 23:47:04 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A86A22F78004; Sat, 30 Oct 2010 00:47:01 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNJRLolmbo0H; Sat, 30 Oct 2010 00:46:56 +0100 (BST) Received: from lert.jifvik.org (jifvik.dyndns.org [85.158.45.40]) by mail.ecoscentric.com (Postfix) with ESMTP id D74262F78001; Sat, 30 Oct 2010 00:46:55 +0100 (BST) Message-ID: <4CCB5CED.4030109@eCosCentric.com> Date: Fri, 29 Oct 2010 23:47:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7 MIME-Version: 1.0 To: gdb-patches@sourceware.org CC: Richard Earnshaw , Kazu Hirata Subject: Re: [patch] Add support for ARMv7M devices. 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> In-Reply-To: <20100816180525.GA13106@caradoc.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-10/txt/msg00396.txt.bz2 On 16/08/10 19:05, Daniel Jacobowitz wrote: > On Thu, Jun 24, 2010 at 09:03:52PM +0100, Richard Earnshaw wrote: >> I'd suggest >> >> org.gnu.gdb.arm.m-profile > > Here's a version addressing comments from Richard, Matthew, and Doug, > and also incorporating Jonathan Larmour's changes. > > I've moved the is_m check lower in arm_pc_is_thumb, to make "set arm > force-mode" continue to do something sensible; you could arguably push > it further down, but this is at least an improvement. > > Tested on ARM EABI and by hand; any comments? Sorry that it's taken me until now to try out this patch. I also see it's checked in to CVS which is fair enough. > 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? > I wouldn't be surprised at an error - any target > which does that, probably also supplies the FPA registers. Indeed it does. And that makes GDB unhappy, claiming the response to the $g packet is too long. > 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. If we change the register layout to avoid the FPA registers in the future, then GDB <= 7.2 won't work, although for that scenario there is at least the possibility of implementing the XML. But I can't do anything about the existing stubs out there, other than get users to reflash their targets which isn't great, or just not use GDB >7.2. The existing GDB debug stubs don't return any XML target description, so we can't go back and add that obviously. So there is a backward compatibility issue. I also wonder about any JTAG debuggers which support Cortex-M (e.g. Ronetix PEEDI). Do they return XML data? I haven't actually tried it with Cortex-M, but looking at a GDB protocol trace with the PEEDI on a different ARM target, no XML info is provided. If that's also true for Cortex-M (which seems likely) then these JTAG debuggers will also stop working. That would probably adversely affect a lot more people than just the developers using the eCos GDB stubs. So I think an alternative may be needed. Either the auto-detection you refer to (although I smell layering violation), or perhaps a 'set' command. Jifl