From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109004 invoked by alias); 31 Mar 2016 18:22:23 -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 108994 invoked by uid 89); 31 Mar 2016 18:22:23 -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_HELO_PASS autolearn=ham version=3.3.2 spammy=agent X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 31 Mar 2016 18:22:13 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C739D804E9; Thu, 31 Mar 2016 18:22:11 +0000 (UTC) Received: from localhost (unused-10-15-17-51.yyz.redhat.com [10.15.17.51]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2VIM9SZ000808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Mar 2016 14:22:11 -0400 From: Sergio Durigan Junior To: Marcin =?utf-8?Q?Ko=C5=9Bcielnicki?= Cc: Ulrich Weigand , gdb-patches@sourceware.org Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. References: <20160330113239.8CC757704@oc7340732750.ibm.com> <56FC4D02.1090207@0x04.net> X-URL: http://blog.sergiodj.net Date: Thu, 31 Mar 2016 18:22:00 -0000 In-Reply-To: <56FC4D02.1090207@0x04.net> ("Marcin =?utf-8?Q?Ko=C5=9Bcielni?= =?utf-8?Q?cki=22's?= message of "Thu, 31 Mar 2016 00:02:42 +0200") Message-ID: <877fgiqzhq.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00604.txt.bz2 On Wednesday, March 30 2016, Marcin Ko=C5=9Bcielnicki wrote: > On 30/03/16 13:32, Ulrich Weigand wrote: >> Marcin Ko=C3=85=E2=80=BAcielnicki wrote: >>> On 29/03/16 20:08, Ulrich Weigand wrote: >>>> Marcin Ko=C3=85=E2=80=BAcielnicki 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. Hi Marcin, Your patch broke the C++ build: Thanks, --=20 Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/