From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26266 invoked by alias); 16 Apr 2012 07:54:27 -0000 Received: (qmail 26257 invoked by uid 22791); 16 Apr 2012 07:54:24 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_MULTIPLE_AT,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Apr 2012 07:54:09 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Mon, 16 Apr 2012 08:54:07 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 16 Apr 2012 08:55:19 +0100 From: "Terry Guo" To: "'Pedro Alves'" , "Jonathan Larmour" Cc: , , "Joey Ye" , "Matthew Gretton-Dann" References: <4F59ED15.1030109@redhat.com> In-Reply-To: <4F59ED15.1030109@redhat.com> Subject: RE: Fwd: Re: [patch] Add support for ARMv7M devices. Date: Mon, 16 Apr 2012 07:56:00 -0000 Message-ID: <001c01cd1ba6$44a2bf50$cde83df0$@guo@arm.com> MIME-Version: 1.0 x-cr-hashedpuzzle: GOR5 It5U JMKS JzMU KfLq NCPJ NTG1 Vive a+ur b0yY huMf k7pc mhpf msqu vjfl vl80;4;ZwBkAGIALQBwAGEAdABjAGgAZQBzAEAAcwBvAHUAcgBjAGUAdwBhAHIAZQAuAG8AcgBnADsAagBpAGYAbABAAGUAYwBvAHMAYwBlAG4AdAByAGkAYwAuAGMAbwBtADsAcABhAGwAdgBlAHMAQAByAGUAZABoAGEAdAAuAGMAbwBtADsAeQBhAG8AQABjAG8AZABlAHMAbwB1AHIAYwBlAHIAeQAuAGMAbwBtAA==;Sosha1_v1;7;{62C159A0-B983-48AF-9FE6-2548B7567369};dABlAHIAcgB5AC4AZwB1AG8AQABhAHIAbQAuAGMAbwBtAA==;Mon, 16 Apr 2012 07:55:04 GMT;UgBFADoAIABGAHcAZAA6ACAAUgBlADoAIABbAHAAYQB0AGMAaABdACAAQQBkAGQAIABzAHUAcABwAG8AcgB0ACAAZgBvAHIAIABBAFIATQB2ADcATQAgAGQAZQB2AGkAYwBlAHMALgA= x-cr-puzzleid: {62C159A0-B983-48AF-9FE6-2548B7567369} X-MC-Unique: 112041608540701601 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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: 2012-04/txt/msg00402.txt.bz2 > -----Original Message----- > From: Pedro Alves [mailto:palves@redhat.com] > Sent: Friday, March 09, 2012 7:44 PM > To: Jonathan Larmour > Cc: gdb-patches@sourceware.org > Subject: Re: Fwd: Re: [patch] Add support for ARMv7M devices. >=20 > On 03/09/2012 04:24 AM, Jonathan Larmour wrote: >=20 > > Over a year ago, after discussion and some helpful pointers from > Daniel, I > > submitted this patch: > > > > http://sourceware.org/ml/gdb-patches/2010-11/msg00142.html > > > > Unfortunately it fell by the wayside. > > > > This issue is coming to a head for the eCos project as we are > updating our > > ARM toolchain (we avoid the bleeding edge). However that means we > really > > need GDB to preserve backward compatibility, which it presently fails > to do. > > > > We don't want to break backward compatibility with installed GDB > stubs, >=20 > > and the XML solution is complicated for users, opaque, not really > suitable >=20 > > for Eclipse (although there may be proprietary plugins around which > try to > > solve this, that isn't relevant for public GDB). Most importantly the > > attached patch should flexibly work everywhere, and not break > anyone's > > compatibility. And furthermore, it allows us a clean migration path > to the > > changed 'g' packet length. > > > > So I'm attaching an updated version of the patch for current GDB > trunk. If > > it helps, I do have an FSF assignment and, from prehistory, commit > > permissions. >=20 >=20 > I support this. I wrote essentially the same without being aware of > your patch: 04/msg00372.html>. >=20 > Wish I had seen yours before that. >=20 > If there are no other comments in a week or so, I say put this in. >=20 > On 03/09/2012 04:24 AM, Jonathan Larmour wrote: > > } > > + else > > + is_m =3D 0; > > >=20 > I think this is unnecessary though. The variable is initialized to 0. >=20 > -- > Pedro Alves Hi, Sorry for bringing it back. Can somebody please tell me how the "guess" mechanism works? How can the buf_len in function process_g_packet become correct with "guess"? Can we just make the arm-with-m.xml always include unnamed FPA registers? So that it can cope with the case with or without FPA registers. Thanks. Terry