From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9962 invoked by alias); 15 Mar 2012 17:09:05 -0000 Received: (qmail 9952 invoked by uid 22791); 15 Mar 2012 17:09:02 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,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; Thu, 15 Mar 2012 17:08:36 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q2FH8YuQ026788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 13:08:34 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q2FH8Wu3008492; Thu, 15 Mar 2012 13:08:33 -0400 Message-ID: <4F622210.7010904@redhat.com> Date: Thu, 15 Mar 2012 17:09:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Jonathan Larmour CC: Pedro Alves , 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> <4F618BA0.6000603@eCosCentric.com> In-Reply-To: <4F618BA0.6000603@eCosCentric.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/msg00551.txt.bz2 On 03/15/2012 06:26 AM, Jonathan Larmour wrote: > 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)? It is called a second time. You can try putting a breakpoint there and see what happens. >From reading the code, we'll reach: /* If we could not find a description using qXfer, and we know how to do it some other way, try again. This is not supported for non-stop; it could be, but it is tricky if there are no stopped threads when we connect. */ if (remote_read_description_p (target) && gdbarch_target_desc (target_gdbarch) == NULL) { target_clear_description (); target_find_description (); } and target_find_description will call gdbarch_update_p, which should end up in gdbarch_find_by_info calling: /* Ask the tdep code for an architecture that matches "info". */ new_gdbarch = rego->init (info, rego->arches); Which will end up in arm_gdbarch_init creating a new gdbarch modelled on the guessed target description (after the checks), since no gdbarch has this tdesc yet. -- Pedro Alves