From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37219 invoked by alias); 14 Mar 2016 17:40:19 -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 37002 invoked by uid 89); 14 Mar 2016 17:40:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.4 required=5.0 tests=BAYES_00,KAM_STOCKGEN,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 spammy=backwards, well! X-HELO: e06smtp05.uk.ibm.com Received: from e06smtp05.uk.ibm.com (HELO e06smtp05.uk.ibm.com) (195.75.94.101) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Mon, 14 Mar 2016 17:40:11 +0000 Received: from localhost by e06smtp05.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Mar 2016 17:40:08 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp05.uk.ibm.com (192.168.101.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 14 Mar 2016 17:40:05 -0000 X-IBM-Helo: d06dlp02.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 2E6BD2190056 for ; Mon, 14 Mar 2016 17:39:47 +0000 (GMT) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2EHe4aV2752958 for ; Mon, 14 Mar 2016 17:40:04 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 u2EHe40X008454 for ; Mon, 14 Mar 2016 11:40:04 -0600 Received: from oc7340732750.ibm.com (icon-9-164-131-203.megacenter.de.ibm.com [9.164.131.203]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2EHe4Vc008447; Mon, 14 Mar 2016 11:40:04 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 698FC1537; Mon, 14 Mar 2016 18:40:03 +0100 (CET) Subject: Re: [PATCH 1/3] gdbserver/IPA: Export some functions via global function pointers. To: simon.marchi@ericsson.com (Simon Marchi) Date: Mon, 14 Mar 2016 17:40:00 -0000 From: "Ulrich Weigand" Cc: koriakin@0x04.net (=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=), gdb-patches@sourceware.org, antoine.tremblay@ericsson.com In-Reply-To: <56E6EFE3.1000301@ericsson.com> from "Simon Marchi" at Mar 14, 2016 01:07:47 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20160314174003.698FC1537@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16031417-0021-0000-0000-000006318078 X-SW-Source: 2016-03/txt/msg00219.txt.bz2 Simon Marchi wrote: > Since we are working on fast tracepoints for ARM, I can provide an > additional data point to the discussion. We have a similar problem, > that is when generating the branch to gdb_collect, we need to know > whether gdb_collect is an ARM or Thumb symbol. If the symbol is an > ARM one, the branch instruction must jump to an even address > (e.g. 0xd3c8), whereas if the symbol is Thumb, the destination address > must have its bit 0 set (e.g. 0xd3c9). Thanks for the additional info, that's quite interesting as well! > To achieve this, we extended qSymbol to allow sending the symbol target > flags (coming from MSYMBOL_TARGET_FLAG_{1,2}). Those flags are target/arch > specific. In the case of ARM, one of them indicates that the symbol is > a Thumb one. This solution works well, but we also have to think about > backwards compatibility of the protocol. It shouldn't be too complicated > however, since we are adding an optional field. > > On the other hand, Marcin's solution would work as well for the ARM > architecture. The compiler would place the right value in gdb_collect_ptr, > regardless of whether gdb_collect is an ARM (bit 0 cleared) or a Thumb > (bit 0 set) symbol. This is similar to the second option I suggested last year, which was to add an extra field to qSymbol so it could return both a code address *and* a function pointer value for function symbols. This it seems would work for your case too, since you could determine ARM vs. Thumb from the function pointer value. On the other hand, I'm now wondering if it makes sense to add extra protocol support to provide function pointer values, when we can just as well use Marcin's trick to simply read a function pointer ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com