From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28934 invoked by alias); 30 Mar 2016 11:38:24 -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 28693 invoked by uid 89); 30 Mar 2016 11:38:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=pierre X-HELO: e06smtp07.uk.ibm.com Received: from e06smtp07.uk.ibm.com (HELO e06smtp07.uk.ibm.com) (195.75.94.103) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 30 Mar 2016 11:38:17 +0000 Received: from localhost by e06smtp07.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 30 Mar 2016 12:38:15 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp07.uk.ibm.com (192.168.101.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 30 Mar 2016 12:38:14 +0100 X-IBM-Helo: d06dlp01.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb-patches@sourceware.org Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 86EE217D805D for ; Wed, 30 Mar 2016 12:38:51 +0100 (BST) Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2UBcDvw4391190 for ; Wed, 30 Mar 2016 11:38:13 GMT Received: from d06av04.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2UBcC6b026259 for ; Wed, 30 Mar 2016 05:38:13 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-105.boeblingen.de.ibm.com [9.152.213.105]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2UBcCBu026246; Wed, 30 Mar 2016 05:38:12 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id E5E0C7704; Wed, 30 Mar 2016 13:38:11 +0200 (CEST) Subject: Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook. To: koriakin@0x04.net (=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=) Date: Wed, 30 Mar 2016 11:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, pierre.langlois@arm.com, yao.qi@linaro.org In-Reply-To: <56FAFBFE.70005@0x04.net> from "=?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?=" at Mar 30, 2016 12:04:46 AM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160330113811.E5E0C7704@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16033011-0029-0000-0000-00000C5328BB X-SW-Source: 2016-03/txt/msg00557.txt.bz2 Marcin Kościelnicki wrote: > On 29/03/16 20:18, Ulrich Weigand wrote: > > Marcin Kościelnicki wrote: > > > >> Targets may have various requirements on the required location of the jump > >> pad area. Currently IPA allocates it at the lowest possible address, > >> so that it is reachable by branches from the executable. However, this > >> fails on powerpc, which has executable link address (0x10000000) much > >> larger than branch reach (+/- 32MiB). > >> > >> This makes jump pad buffer allocation a target hook instead. The current > >> implementations are as follows: > >> > >> - i386: Branches can reach anywhere, so just mmap it. This avoids > >> the linear search dance. > >> - x86_64: Branches have +/-2GiB of reach, and executable is loaded low, > >> so just call mmap with MAP_32BIT. Likewise avoids the linear search. > >> - aarch64: Branches have +-128MiB of reach, executable loaded at 4MiB. > >> Do a linear search from 4MiB-size downwards to page_size. > > > > This makes sense to me, but I agree that this needs testing on the > > affected platforms, in particular aarch64. > > Right. I've tested on i386 and x86_64. Unfortunately I have no means > of testing on aarch64 - could someone lend a hand here? Pierre or Yao ... you've been working in this area recently, could you have a look at Marcin's patch and give it a test? Thanks! > Also, since s390 tracepoints have just landed, I'll update the patch to > cover s390 and s390x as well. > > > >> +void *alloc_jump_pad_buffer (size_t size); > >> +#ifdef HAVE_GETAUXVAL > >> +unsigned long getauxval (unsigned long type); > >> +#endif > > > > Shouldn't this use a guard like > > #if !defined HAVE_GETAUXVAL && defined IN_PROCESS_AGENT > > just as in the source file? > > Whoops, you're obviously right - I'm going to change the guard to > #ifndef HAVE_GETAUXVAL (since it's already inside #ifdef > IN_PROCESS_AGENT). I'll send this fix in v3 along with s390 support. OK, thanks! Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com