From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121835 invoked by alias); 14 Mar 2016 14:53:53 -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 121823 invoked by uid 89); 14 Mar 2016 14:53:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=bfd, HContent-Transfer-Encoding:8bit X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (109.74.193.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Mar 2016 14:53:50 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id 2F15F3FE6E; Mon, 14 Mar 2016 15:54:48 +0100 (CET) Received: from [192.168.1.62] (84-10-2-59.static.chello.pl [84.10.2.59]) by hogfather.0x04.net (Postfix) with ESMTPSA id D2690580089; Mon, 14 Mar 2016 15:53:47 +0100 (CET) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand References: <20160314144140.CC00C1537@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56E6D07B.5050306@0x04.net> Date: Mon, 14 Mar 2016 14:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160314144140.CC00C1537@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00212.txt.bz2 On 14/03/16 15:41, Ulrich Weigand wrote: > Marcin Kościelnicki wrote: > >> 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. > > 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 > > At the time, I suggested two possible fixes by changing how qSymbol works. > Your approach is yet another fix, however ... > > 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. > Yeah, I'm not that happy with it either... but we're going to need to jump through some hoops in gdbserver anyway - eg. for gdb_collect, we need the descriptor address, while for stop_tracing, we need the code address. So we will need some special handling for one of these sets of symbols either way, and uglify the common code with it. > 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. It works *sometimes* - I'm not sure what it depends on, as I'm not familiar with BFD internals, but it seems gdb could have the necessary information cached and not need to read the file during qSymbol processing. I, for one, had one hell of a debugging session, since my simple test program linked against the IPA had all the IPA symbols properly fetched, while the testsuite programs failed at the same. Could be something like library load order... > > 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? > > 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.) Yep, I thought about it, but there's the protocol compatibility issue... > > Bye, > Ulrich >