From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16166 invoked by alias); 17 Apr 2012 01:56:26 -0000 Received: (qmail 16069 invoked by uid 22791); 17 Apr 2012 01:56:26 -0000 X-SWARE-Spam-Status: No, hits=-2.7 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; Tue, 17 Apr 2012 01:55:54 +0000 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.21]) by service87.mimecast.com; Tue, 17 Apr 2012 02:55:52 +0100 Received: from shawin053 ([10.1.255.212]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 17 Apr 2012 02:57:04 +0100 From: "Terry Guo" To: "'Jonathan Larmour'" Cc: References: <4F59ED15.1030109@redhat.com> <001c01cd1ba6$44a2bf50$cde83df0$@guo@arm.com> <4F8C2C53.8070306@eCosCentric.com> In-Reply-To: <4F8C2C53.8070306@eCosCentric.com> Subject: RE: Fwd: Re: [patch] Add support for ARMv7M devices. Date: Tue, 17 Apr 2012 04:06:00 -0000 Message-ID: <001e01cd1c3d$635fd4e0$2a1f7ea0$@guo@arm.com> MIME-Version: 1.0 X-MC-Unique: 112041702555200201 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/msg00448.txt.bz2 > -----Original Message----- > From: Jonathan Larmour [mailto:jifl@ecoscentric.com] > Sent: Monday, April 16, 2012 10:28 PM > To: Terry Guo > Cc: gdb-patches@sourceware.org; Joey Ye; Matthew Gretton-Dann > Subject: Re: Fwd: Re: [patch] Add support for ARMv7M devices. >=20 > On 16/04/12 08:55, Terry Guo wrote: > > > > Can somebody please tell me how the "guess" mechanism works? How can > the > > buf_len in function process_g_packet become correct with "guess"? >=20 > Have a look at remote_read_description(), which is called early on when > connecting to the target. Once the target description (tdesc) is set > from > there, subsequent calls to process_g_packet() will have an appropriate > value for sizeof_g_packet. >=20 That's exact how the "guess" works! I get it. Thanks. > > 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. >=20 > I think that it might have been possible to arrange this if the FPA > registers happened to be sent at the very end of the "normal" register > set > (courtesy of some handling in process_g_packet() of smaller 'g' > packets). > But i don't think that's possible here given the FPA regs come after > the > PC but before the XPSR at the end; at least not without adding much > more > machinery somewhere, including extending the target description syntax. > I > might be wrong though, as I don't know the ins-and-outs of this code as > well as others here. >=20 > Jifl I get your point and think you are correct. If we always assume faked FPA registers, we will mess things up when the stub only returns core register + xpsr. BR, Terry