From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46045 invoked by alias); 30 Mar 2016 22:02:57 -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 46026 invoked by uid 89); 30 Mar 2016 22:02:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2138, agent, H*MI:sk:2016033, 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; Wed, 30 Mar 2016 22:02:46 +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 581611AA44; Wed, 30 Mar 2016 22:02:43 +0000 (UTC) Received: from [172.21.36.130] (unknown [88.214.185.169]) by hogfather.0x04.net (Postfix) with ESMTPSA id 18EAC580114; Thu, 31 Mar 2016 00:02:43 +0200 (CEST) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand References: <20160330113239.8CC757704@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56FC4D02.1090207@0x04.net> Date: Wed, 30 Mar 2016 22:02: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: <20160330113239.8CC757704@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/msg00578.txt.bz2 On 30/03/16 13:32, Ulrich Weigand wrote: > 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. I've resolved a trivial interaction with the s390 changes pushed in the meantime (linux-s390-ipa.c needs an identical fix to the others) and pushed it. > > Thanks, > Ulrich >