From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 643 invoked by alias); 20 Apr 2012 13:20:26 -0000 Received: (qmail 633 invoked by uid 22791); 20 Apr 2012 13:20:24 -0000 X-SWARE-Spam-Status: No, hits=-7.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 13:20:09 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q3KDK2EO003383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Apr 2012 09:20:03 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q3KDK19H003926; Fri, 20 Apr 2012 09:20:01 -0400 Message-ID: <4F916280.2080100@redhat.com> Date: Fri, 20 Apr 2012 13:22:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Terry Guo CC: Jonathan Larmour , gdb-patches@sourceware.org, Ilija Kocho Subject: Re: [patch] Add support for VFP d16 layout for Cortex-M4 References: <4F902B4E.9070704@eCosCentric.com> <4F91593B.4020309@redhat.com> <001501cd1ef7$bd79e490$386dadb0$@guo@arm.com> In-Reply-To: <001501cd1ef7$bd79e490$386dadb0$@guo@arm.com> 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: 2012-04/txt/msg00677.txt.bz2 Hi Terry, On 04/20/2012 02:16 PM, Terry Guo wrote: > From: Pedro Alves [mailto:palves@redhat.com] >> I'd like to make it clear that the guesses mechanism is a just a >> fallback >> mechanism, useful when its too late to change the stubs out there to >> send the xml description to gdb themselves. It's not the ideal way >> forward, >> and it can't scale beyond a few guesses. The right thing is for >> the stubs themselves to report the xml descriptions to GDB (with >> qXfer:features:read), >> not to have them depend on GDB being able to guess it. >> > > Ideally using the qXfer:features:read is the most natural way. Can you > confirm that once it is used, the guess mechanism won't be resorted for M4? > The code in trunk already has two guess methods for Cortex-M. I don't want > things get messed up. Correct. If the target returns a xml description with qXfer:features:read, the guess mechanism is never triggered. > > Another thing in my mind is as Jonathan said before, the stub that will be > programmed into flash is sensitive to the bytes. So I guess they may tend to > save bytes by not returning target.xml. I am not sure what I am assuming is > true. Please correct me if I am wrong. -- Pedro Alves