From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12314 invoked by alias); 29 Mar 2016 18:18:56 -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 12302 invoked by uid 89); 29 Mar 2016 18:18:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=dance, lowest, HContent-Transfer-Encoding:8bit X-HELO: e06smtp08.uk.ibm.com Received: from e06smtp08.uk.ibm.com (HELO e06smtp08.uk.ibm.com) (195.75.94.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 29 Mar 2016 18:18:55 +0000 Received: from localhost by e06smtp08.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 29 Mar 2016 19:18:52 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp08.uk.ibm.com (192.168.101.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 29 Mar 2016 19:18:50 +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 DB06F17D8042 for ; Tue, 29 Mar 2016 19:19:27 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u2TIIoXi8257796 for ; Tue, 29 Mar 2016 18:18:50 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u2TIInBK004332 for ; Tue, 29 Mar 2016 12:18:50 -0600 Received: from oc7340732750.ibm.com (dyn-9-152-213-47.boeblingen.de.ibm.com [9.152.213.47]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u2TIInYD004323; Tue, 29 Mar 2016 12:18:49 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id A8017C9C7; Tue, 29 Mar 2016 20:18:49 +0200 (CEST) Subject: Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook. To: koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) Date: Tue, 29 Mar 2016 18:18:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, koriakin@0x04.net (=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=) In-Reply-To: <1458313693-5679-1-git-send-email-koriakin@0x04.net> from "=?UTF-8?q?Marcin=20Ko=C5=9Bcielnicki?=" at Mar 18, 2016 04:08:13 PM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20160329181849.A8017C9C7@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16032918-0033-0000-0000-00000AE614C7 X-SW-Source: 2016-03/txt/msg00529.txt.bz2 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. > +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? Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com