From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6804 invoked by alias); 30 Mar 2016 11:32:58 -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 6787 invoked by uid 89); 30 Mar 2016 11:32:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1987, agent, HContent-Transfer-Encoding:8bit X-HELO: e06smtp17.uk.ibm.com Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 30 Mar 2016 11:32:47 +0000 Received: from localhost by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Mar 2016 12:32:43 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 30 Mar 2016 12:32:40 +0100 X-IBM-Helo: d06dlp03.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 d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3E52F1B08061 for ; Wed, 30 Mar 2016 12:33:15 +0100 (BST) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2UBWe9o62128226 for ; Wed, 30 Mar 2016 11:32:40 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2UBWd9R018501 for ; Wed, 30 Mar 2016 05:32:40 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-105.boeblingen.de.ibm.com [9.152.213.105]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2UBWdZ8018495; Wed, 30 Mar 2016 05:32:39 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 8CC757704; Wed, 30 Mar 2016 13:32:39 +0200 (CEST) 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: Wed, 30 Mar 2016 11:32:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org In-Reply-To: <56FAF911.7000209@0x04.net> from "=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=" at Mar 29, 2016 11:52:17 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160330113239.8CC757704@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16033011-0005-0000-0000-00000F772AA4 X-SW-Source: 2016-03/txt/msg00556.txt.bz2 Marcin Kościelnicki wrote: > On 29/03/16 20:08, Ulrich Weigand wrote: > > Marcin Kościelnicki wrote: > >> On 14/03/16 18:49, Ulrich Weigand wrote: > >>> 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 ... > >> > >> Alright, so what should we do about this issue? > > > > Since nobody came up with a better idea, and since your patch doesn't > > actually preclude anybody from implementing any better idea they might > > come up later (since it doesn't actually change anything in the > > gdbserver protocol), I'd say we just go with your patch for now. > > Very well, then. For this to be actually useful for powerpc64, I'll > also need an ack on the other patch > (https://sourceware.org/ml/gdb-patches/2016-03/msg00201.html). This looks to be resolved now. > > However, there does seem to be one issue: your patch changes the > > interface between gdbserver and the in-process agent in an incompatible > > way. Binaries with an old IPA built in will no longer work with a > > new gdbserver, since it will will expect exported symbols like > > gdb_collect_ptr, which the old binary doesn't export. > > > > I think it would be preferable to implement a backward-compatible > > way where gdbserver checks for the new symbol, and if it isn't > > present, falls back to the old symbol. > > Alright, I can do that, though I seem to recall we don't care about > gdbserver/IPA interface compatibility (and IPA is always built as > shared, so there's no concern about an executable with old version built > in). And this turns out to be not necessary after all, see the recent mail by Pedro. Sorry for the confusion. I think the patch should be OK now. Thanks, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com