From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61357 invoked by alias); 14 Mar 2016 17:08:03 -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 61337 invoked by uid 89); 14 Mar 2016 17:08:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,SPF_PASS autolearn=no version=3.3.2 spammy=backwards, 160314 X-HELO: usplmg20.ericsson.net Received: from usplmg20.ericsson.net (HELO usplmg20.ericsson.net) (198.24.6.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 14 Mar 2016 17:07:52 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 2E.45.12433.CCAE6E65; Mon, 14 Mar 2016 17:46:04 +0100 (CET) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.248.2; Mon, 14 Mar 2016 13:07:47 -0400 Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand , =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= References: <20160314144140.CC00C1537@oc7340732750.ibm.com> CC: , From: Simon Marchi Message-ID: <56E6EFE3.1000301@ericsson.com> Date: Mon, 14 Mar 2016 17:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160314144140.CC00C1537@oc7340732750.ibm.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00218.txt.bz2 On 16-03-14 10:41 AM, Ulrich Weigand wrote: > Marcin Ko=C5>cielnicki wrote: >=20 >> On powerpc64, qSymbol for a function returns the function code address, >> and not the descriptor address. Since we emit code calling gdb_collect >> and some other functions, we need the descriptor (no way to know the >> proper TOC address without it). To get the descriptor address, make >> global function pointer variables in the IPA pointing to the relevant >> functions and read them instead of asking for them directly via qSymbol. >=20 > Huh. This problem already came up last year with Wei-cheng's patches. > See my reply here: > https://sourceware.org/ml/gdb-patches/2015-02/msg00838.html >=20 > At the time, I suggested two possible fixes by changing how qSymbol works. > Your approach is yet another fix, however ... >=20 > I'm not sure I really like your approach, it seems odd to make common > code jump through "unnatural" hoops just so that powerpc64 works. > On the other hand, your approach certainly involves the least amount > of changes to the current code base. >=20 > I am somewhat confused about one thing, though. In your other patch > https://sourceware.org/ml/gdb-patches/2016-03/msg00201.html > you seem to imply that qSymbol for function symbols simply does not > work at all on powerpc64 at the moment. >=20 > If this is true, how does thread-db support work? This is the one > pre-existing user of qSymbol for function symbols in gdbserver. > I had been under the assumption that this actually works now. Is > this not in fact true? >=20 > If this is indeed just completely broken at the moment, my > preferred fix would actually be to change qSymbol to just return > the function descriptor address (i.e. work as on any other platform) > and have the function descriptor -> function code address lookup > be done on the gdbserver side when necessary for thread-db support. > (This would have been my preferred fix anyway, except for the fact > that it breaks protocol compatibility. However, if the current > implementation simply doesn't *work*, there's no reason to worry > about compatibility.) >=20 > Bye, > Ulrich Since we are working on fast tracepoints for ARM, I can provide an additional data point to the discussion. We have a similar problem, that is when generating the branch to gdb_collect, we need to know whether gdb_collect is an ARM or Thumb symbol. If the symbol is an ARM one, the branch instruction must jump to an even address (e.g. 0xd3c8), whereas if the symbol is Thumb, the destination address must have its bit 0 set (e.g. 0xd3c9). To achieve this, we extended qSymbol to allow sending the symbol target flags (coming from MSYMBOL_TARGET_FLAG_{1,2}). Those flags are target/arch specific. In the case of ARM, one of them indicates that the symbol is a Thumb one. This solution works well, but we also have to think about backwards compatibility of the protocol. It shouldn't be too complicated however, since we are adding an optional field. On the other hand, Marcin's solution would work as well for the ARM architecture. The compiler would place the right value in gdb_collect_ptr, regardless of whether gdb_collect is an ARM (bit 0 cleared) or a Thumb (bit 0 set) symbol. Simon