From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9354 invoked by alias); 14 Mar 2012 16:06:37 -0000 Received: (qmail 9340 invoked by uid 22791); 14 Mar 2012 16:06:35 -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; Wed, 14 Mar 2012 16:06:19 +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 q2EG6Det029345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 14 Mar 2012 12:06:13 -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 q2EG6BfK020466; Wed, 14 Mar 2012 12:06:12 -0400 Message-ID: <4F60C1F3.30504@redhat.com> Date: Wed, 14 Mar 2012 16:06: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 , Yao Qi , 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> In-Reply-To: <4F5C1DCA.5080309@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/msg00484.txt.bz2 On 03/11/2012 03:36 AM, Jonathan Larmour wrote: > On 09/03/12 16:28, Pedro Alves wrote: >> On 03/09/2012 04:13 PM, Jonathan Larmour wrote: >>> >>> But you have made me think of one improvement: we should probably not call >>> register_remote_g_packet_guess() if tdesc_has_registers (tdesc) - because >>> if someone has directly supplied a target description, we should solely >>> use that, and avoid any guessing. >> >> >> I think that's always true, irrespective of a g packet guess being >> installed. See target_find_description: it's always "file > target xml > g-guesses", > > 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). Or did you mean, in the case where the target does send over a target description? The g packet size guesses are only used when the target does _not_ send in a target description. So, GDB, during the initial remote connection, calls target_find_description: void target_find_description (void) { /* If we've already fetched a description from the target, don't do it again. This allows a target to fetch the description early, during its to_open or to_create_inferior, if it needs extra information about the target to initialize. */ if (target_desc_fetched) return; /* The current architecture should not have any target description specified. It should have been cleared, e.g. when we disconnected from the previous target. */ gdb_assert (gdbarch_target_desc (target_gdbarch) == NULL); /* First try to fetch an XML description from the user-specified file. */ current_target_desc = NULL; if (target_description_filename != NULL && *target_description_filename != '\0') current_target_desc = file_read_description_xml (target_description_filename); /* Next try to read the description from the current target using target objects. */ if (current_target_desc == NULL) current_target_desc = target_read_description_xml (¤t_target); /* If that failed try a target-specific hook. */ if (current_target_desc == NULL) current_target_desc = target_read_description (¤t_target); Which you can see first checks for a description as set by "set tdesc filename", and if that doesn't work, tries to fetch a description off the target, and only if that doesn't work, it'll call target_read_description, which maps to remote_read_description, which returns a guess based on the size of the g packet, as registered on the gdbarch. So if the target replied back a xml target description, we'll never read the target_read_description call. There's actually a wrinkle: during the first call to target_find_description, we haven't yet fetched the remote thread and inferior's status, and haven't yet added them to our tables. So that first very initial time, remote_read_description returns nothing. Right after fetching the remote target's status, we then try again: /* 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 (); } But again, if the target or the user have already specified a description, the if predicate is false. If we don't have a description yet, we'll end up in target_find_description -> remote_read_description, which will no return the best description for the gdbarch based on the g packet size. Of course, the g-guesses are registered on specific gdbarch's. So GDB already needs to have a clue of the target's gdbarch for g-packet guesses to work. And again, it gets that initial target_gdbarch from the executable. -- Pedro Alves