From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26799 invoked by alias); 22 Mar 2016 09:19:04 -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 26775 invoked by uid 89); 22 Mar 2016 09:19:03 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HTo:U*uweigand, imply, Bye, 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; Tue, 22 Mar 2016 09:19:02 +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 95ECA3FED4; Tue, 22 Mar 2016 10:20:02 +0100 (CET) Received: from [192.168.1.98] (unknown [62.28.189.238]) by hogfather.0x04.net (Postfix) with ESMTPSA id 5ABFC580088; Tue, 22 Mar 2016 10:18:59 +0100 (CET) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand References: <20160314174925.5A6541537@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56F10E02.2090403@0x04.net> Date: Tue, 22 Mar 2016 09:19: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: <20160314174925.5A6541537@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/msg00448.txt.bz2 On 14/03/16 18:49, Ulrich Weigand wrote: > Marcin Kościelnicki wrote: >> On 14/03/16 15:41, Ulrich Weigand wrote: >>> 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. > > That's certainly true as well. Also, implementing the descriptor to > code address lookup in exactly the same way as GDB does might be > difficult for gdbserver to do, since it is currently reading the BFD, > which gdbserver doesn't have available. > >>> 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... > > Hmm. I just checked, and it turns out that as of Dec 2015 gdbserver > actually no longer even uses the td_ta_set_event libthread_db > callback at all. Instead, it now always relies on PTRACE_EVENT_CLONE > to detect new inferior threads. This means that thread support > shouldn't actually require qSymbol on a function symbol any more. > > In addition, it probably used to work in the past because GDB only > uses the vFile packet when it is reading the target libraries from > the target itself. In past, GDB usually required copies of the > target libraries to be present on the host system as well, and > used them from there. While there was support for loading target > libraries remotely for a while, it was only made default about > a year ago. > > >> Yep, I thought about it, but there's the protocol compatibility issue... > > The more I think about it, the more I tend to agree that your > proposal is actually the best solution. I'd still like to give > it a couple of days to give others a chance to comment as well ... > > Bye, > Ulrich > Alright, so what should we do about this issue?