From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97595 invoked by alias); 29 Mar 2016 21:52:32 -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 97581 invoked by uid 89); 29 Mar 2016 21:52:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1645, agent, HContent-Transfer-Encoding:8bit X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (159.100.250.38) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Mar 2016 21:52:21 +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 721A91A3BB; Tue, 29 Mar 2016 21:52:18 +0000 (UTC) Received: from [172.21.36.130] (unknown [88.214.186.105]) by hogfather.0x04.net (Postfix) with ESMTPSA id 48C0B5800F8; Tue, 29 Mar 2016 23:52:18 +0200 (CEST) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand References: <20160329180835.1AA33C9C7@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56FAF911.7000209@0x04.net> Date: Tue, 29 Mar 2016 21:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160329180835.1AA33C9C7@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/msg00541.txt.bz2 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). > 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). > > Bye, > Ulrich >