From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109208 invoked by alias); 14 Mar 2016 17:49:39 -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 109149 invoked by uid 89); 14 Mar 2016 17:49:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2825, HContent-Transfer-Encoding:8bit X-HELO: e06smtp07.uk.ibm.com Received: from e06smtp07.uk.ibm.com (HELO e06smtp07.uk.ibm.com) (195.75.94.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 14 Mar 2016 17:49:34 +0000 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Mar 2016 17:49:30 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 14 Mar 2016 17:49:28 -0000 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D7C0F2190046 for ; Mon, 14 Mar 2016 17:49:08 +0000 (GMT) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2EHnQ6l393500 for ; Mon, 14 Mar 2016 17:49:26 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2EHnQOJ007505 for ; Mon, 14 Mar 2016 11:49:26 -0600 Received: from oc7340732750.ibm.com (icon-9-164-131-203.megacenter.de.ibm.com [9.164.131.203]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2EHnQO6007502; Mon, 14 Mar 2016 11:49:26 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 5A6541537; Mon, 14 Mar 2016 18:49:25 +0100 (CET) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: koriakin@0x04.net (=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=) Date: Mon, 14 Mar 2016 17:49:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <56E6D07B.5050306@0x04.net> from "=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=" at Mar 14, 2016 03:53:47 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160314174925.5A6541537@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16031417-0029-0000-0000-000006471B9C X-SW-Source: 2016-03/txt/msg00220.txt.bz2 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 -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com