From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78292 invoked by alias); 14 Mar 2016 14:41:50 -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 78271 invoked by uid 89); 14 Mar 2016 14:41:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Export, Hx-languages-length:2159, unnatural, HContent-Transfer-Encoding:8bit X-HELO: e06smtp05.uk.ibm.com Received: from e06smtp05.uk.ibm.com (HELO e06smtp05.uk.ibm.com) (195.75.94.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 14 Mar 2016 14:41:48 +0000 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Mar 2016 14:41:45 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 14 Mar 2016 14:41:41 -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 b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id A2F072190046 for ; Mon, 14 Mar 2016 14:41:23 +0000 (GMT) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2EEffcx62521480 for ; Mon, 14 Mar 2016 14:41:41 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2EEffnC014989 for ; Mon, 14 Mar 2016 10:41:41 -0400 Received: from oc7340732750.ibm.com (dyn-9-152-213-148.boeblingen.de.ibm.com [9.152.213.148]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2EEff4f014976; Mon, 14 Mar 2016 10:41:41 -0400 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id CC00C1537; Mon, 14 Mar 2016 15:41:40 +0100 (CET) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) Date: Mon, 14 Mar 2016 14:41:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) In-Reply-To: <1457836296-29974-2-git-send-email-koriakin@0x04.net> from "=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=" at Mar 13, 2016 03:31:34 AM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160314144140.CC00C1537@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16031414-0021-0000-0000-00000630C4FE X-SW-Source: 2016-03/txt/msg00211.txt.bz2 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. 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. 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.) Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com