From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31487 invoked by alias); 13 Feb 2017 12:55:28 -0000 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 Received: (qmail 31458 invoked by uid 89); 13 Feb 2017 12:55:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=right!, right, H*RU:HELO, Hx-spam-relays-external:HELO X-HELO: mga09.intel.com Received: from mga09.intel.com (HELO mga09.intel.com) (134.134.136.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 13 Feb 2017 12:55:25 +0000 Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2017 04:55:23 -0800 X-ExtLoop1: 1 Received: from labpc305.iul.intel.com (HELO [172.28.50.132]) ([172.28.50.132]) by orsmga002.jf.intel.com with ESMTP; 13 Feb 2017 04:55:22 -0800 Subject: Re: [PATCH V7] amd64-mpx: initialize bnd register before performing inferior calls. To: Pedro Alves , qiyaoltc@gmail.com, brobecker@adacore.com References: <1485875613-31975-1-git-send-email-walfred.tedeschi@intel.com> <53d42bb6-3b83-6213-4087-6d30e7d837de@redhat.com> <217a8c13-b7d0-7fe6-56b5-85ff53ce097a@intel.com> <88c7180f-8843-a148-425a-2adf56c6d0bf@redhat.com> <32693426-fbaf-8345-04c7-e2c329d6ec6e@intel.com> <75843d02-1b8b-f726-c36d-cd05c0ea5339@redhat.com> Cc: gdb-patches@sourceware.org From: "Tedeschi, Walfred" Message-ID: Date: Mon, 13 Feb 2017 12:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <75843d02-1b8b-f726-c36d-cd05c0ea5339@redhat.com> Content-Type: text/plain; charset="windows-1252"; format="flowed" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-02/txt/msg00335.txt.bz2 On 02/13/2017 01:03 PM, Pedro Alves wrote: > On 02/13/2017 08:33 AM, Tedeschi, Walfred wrote: > >> On 02/08/2017 01:27 PM, Pedro Alves wrote: >>> For passing local pointers to some function, it might be >>> that GDB could be able to figure out which bound registers >>> contains the bound for a given variable, or if spilled, where >>> to find then, and set up the call to use the right bounds, but >>> I have no idea of how to retrieve that information. I suspect >>> that it's not a mapping we could retrieve from the dwarf? And >>> then there's also the case of passing pointers to global >>> variables, and pointers to memory that gdb malloc's into the >>> inferior, like for array/string coercion: >> ABI defines which BND is used for which parameter and what to do when it >> is needed to pass more bounds than BND registers available. > Sure, but ABI only specifies calling convention, not > whatever the compiler decides to do inside the function bodies, > right? Say: > > extern void bar (int *ptr); > > void foo (int *ptr) > { > // lots of code code here. > [...] > > // PTR now lives in memory, or in a different register > // The corresponding BND register could have been > // spilled/reused too. > > // do "call bar (ptr)" from the debugger while stopped here. > // How would GDB determine where the correct corresponding > // BND value is? > } > > I haven't studied the BND documention in detail, but I don't > imagine how the information necessary to be able to answer the > question in the comment above, in the general case, could be > determined from ABI-awareness alone, and I don't believe it's > something that could be retrieved from DWARF either. But > I'd gladly be shown wrong. You are absolutely right! there is no way to know what goes on with the=20 BND register within the code itself. Internally we have discussed how to represent the bound information on=20 DWARF, but for one reason or another we did not arrive at the point to formalize it and bring it to the committee. Basically idea was to add as a new DW_AT that would work as a location=20 list for the bounds of any type that would point to a DW_TAG_POINTER_TYPE, DW_TAG_REFERENCE_TYPE or DW_rvalue_reference_type. We still intend to bring this proposal to the committee. >> if we set afterwards: Inferior call + Break point + register set. >> we should not need any additional set and show for the architecture. >> Hover as you pointed out in the other e-mail it is better to increase >> testing and document it. > Agreed, that sounds like a reasonable way to handle that use case. > I think mentioning it in the documentation would be good. > > Thanks, > Pedro Alves > I am working on the tests right now! Thanks again for your review and best regards, /Fred Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Christian Lamprechter Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928