From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96106 invoked by alias); 29 Mar 2016 21:51:25 -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 95995 invoked by uid 89); 29 Mar 2016 21:51:24 -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=coupling, 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; Tue, 29 Mar 2016 21:51:24 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id A4C75AA5; Tue, 29 Mar 2016 21:51:22 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2TLpLLw012837; Tue, 29 Mar 2016 17:51:21 -0400 Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: Ulrich Weigand , =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= References: <20160329180835.1AA33C9C7@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <56FAF8D8.1070207@redhat.com> Date: Tue, 29 Mar 2016 21:51: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 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-03/txt/msg00540.txt.bz2 On 03/29/2016 07:08 PM, Ulrich Weigand wrote: > 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. So far, given the tight coupling between gdbserver and the IPA's implementation, we've required that gdbserver and the IPA must be of the same version. We're added new functions to the interface before without trying to maintain backwards compatibility. Thanks, Pedro Alves