From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16545 invoked by alias); 15 Mar 2012 06:27:01 -0000 Received: (qmail 16527 invoked by uid 22791); 15 Mar 2012 06:26:59 -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; Thu, 15 Mar 2012 06:26:44 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 7993D2F78004; Thu, 15 Mar 2012 06:26:43 +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 1HRiXs8vXleF; Thu, 15 Mar 2012 06:26:41 +0000 (GMT) Message-ID: <4F618BA0.6000603@eCosCentric.com> Date: Thu, 15 Mar 2012 06:27:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.16 MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: Fwd: Re: [patch] Add support for ARMv7M devices. References: <4F598611.4020506@eCosCentric.com> <4F5A240C.1010702@codesourcery.com> <4F5A2C12.6000300@eCosCentric.com> <4F5A2FBE.2070201@redhat.com> <4F5C1DCA.5080309@eCosCentric.com> <4F60C1F3.30504@redhat.com> In-Reply-To: <4F60C1F3.30504@redhat.com> Content-Type: text/plain; charset=UTF-8 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-03/txt/msg00523.txt.bz2 On 14/03/12 16:06, Pedro Alves wrote: > On 03/11/2012 03:36 AM, Jonathan Larmour wrote: >> >> Can you just clarify to me how, for example, a program using VFP registers >> (such as for Cortex-M4) would use the correct 'g' packet size? The >> registers correspond to the tdesc, and not to either of the guessed sizes. >> I guess if I could understand that example, I'll be happy. You can do this >> off list if you like, to save others from boredom. > > Even without a description, and before connecting to the remote side, > GDB already has a clue of the target's architecture, inferred from the > executable. GDB updates target_gdbarch based on that, and sets an initial > expected size of the g packet based on the register set it things the > target has (based on what it figured out from the executable). > > static void * > init_remote_state (struct gdbarch *gdbarch) > { > ... > /* Record the maximum possible size of the g packet - it may turn out > to be smaller. */ > rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs); > > If it turns out to be smaller, GDB will re-adjust (process_g_packet). Ah ok, that's what I was missing. And that uses gdbarch_num_regs() which corresponds to arm-tdep.h's ARM_NUM_REGS which includes all possible registers, both VFP and FPA. And later the 'g' packet is shrunk. So, just to be clear, if neither the user nor target supplies a tdesc, the block in arm_gdbarch_init() starting with: if (tdesc_has_registers (tdesc)) will never be run? If that's the case, no need to answer. Or is arm_gdbarch_init() called a second time after the remote 'g' packet guessing occurs (which has selected a tdesc)? > Or did you mean, in the case where the target does send over a > target description? No I was thinking more of when GDB only has the executable to go on. But thanks for that information - it fills other gaps in my knowledge. 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. ** Visit us at the ESC Expo at Design West in San Jose ** ** 27-29 March, McEnery Convention Center - Stand #846 ** ------["Si fractum non sit, noli id reficere"]------ Opinions==mine