From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9705 invoked by alias); 3 Nov 2010 03:21:39 -0000 Received: (qmail 9681 invoked by uid 22791); 3 Nov 2010 03:21:38 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,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; Wed, 03 Nov 2010 03:21:33 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E68E02F80004 for ; Wed, 3 Nov 2010 03:21:30 +0000 (GMT) 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 QhJCrZ5Izeoi; Wed, 3 Nov 2010 03:21:27 +0000 (GMT) Message-ID: <4CD0D534.90701@eCosCentric.com> Date: Wed, 03 Nov 2010 03:21: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 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> <4CCB5CED.4030109@eCosCentric.com> <20101101033953.GA15714@caradoc.them.org> In-Reply-To: <20101101033953.GA15714@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-11/txt/msg00060.txt.bz2 On 01/11/10 03:39, Daniel Jacobowitz wrote: > On Sat, Oct 30, 2010 at 12:46:53AM +0100, Jonathan Larmour wrote: >> 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. Oh, I see. Presumably to work around the absence of this patch! > Are your stubs returning FPA registers and a fake CPSR, or are they > returning FPA registers and an XPSR? Both are pretty wonky. FPA registers and an XPSR. Because up to this patch (so including GDB 7.2) the FPA registers were expected by GDB by default. We and others just complied with GDB's requirements. >>> 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. Well, it won't work "out of the box". > 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. Alas, this isn't so easy for GUI users, including Eclipse users. > 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. Ah, I thought you had already got an idea for how auto-detection would work. >> 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. I was able to try a PEEDI on a Cortex-M board today. It definitely does not support XML-based target descriptions in general. I'd be amazed if it was alone. I can confirm that everything appears ok if I do provide an appropriate target description using "set tdesc ...". I do understand that Cortex-M (or anything marked as EABI) doesn't have FPA registers, but nor have most ARM cores for a long time. There are quite a number of JTAG models out there which claim to support Cortex-M with GDB. Given what this patch adds, none of them would support returning the correct target description (it would have to reference "org.gnu.gdb.arm.m-profile" so that gdbarch->is_m gets set, but that feature is only added in this patch). I think there's a more general issue here about whether it's expected to maintain support for existing working stub implementations such that they can be used as they have been used even when GDB is upgraded. Changing the interface with GDB remote stubs used to be a big no-no for GDB. But is it now the case with the target description support that it's considered acceptable to break compatibility with _existing_ stubs as long as a target description file can fix it back up again? I think some users would struggle working out what the cause of failures like "Remote 'g' packet reply is too long" is, nevermind how to fix this after starting to use a newer GDB. If this is the policy then that's fine, as long as people understand that. If it's not, then the FPA regs (even though unused in EABI) perhaps ought to go back in. No matter what I can deal with my own GDB stub whatever is decided; I'm a bit more concerned about the JTAG debuggers. I'm fully expecting you to tell me that this is the policy now and the JTAG manufacturers will have to work out how to update customers in the field, but I'd like to know for definite. Jifl -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["Si fractum non sit, noli id reficere"]------ Opinions==mine