From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38956 invoked by alias); 29 Mar 2016 22:04: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 38935 invoked by uid 89); 29 Mar 2016 22:04:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=landed, Hx-languages-length:1789, dance, lowest X-HELO: xyzzy.0x04.net Received: from xyzzy.0x04.net (HELO xyzzy.0x04.net) (159.100.250.38) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Mar 2016 22:04:50 +0000 Received: from hogfather.0x04.net (89-65-66-135.dynamic.chello.pl [89.65.66.135]) by xyzzy.0x04.net (Postfix) with ESMTPS id 88C071A3BB; Tue, 29 Mar 2016 22:04:47 +0000 (UTC) Received: from [172.21.36.130] (unknown [88.214.186.105]) by hogfather.0x04.net (Postfix) with ESMTPSA id 4ED9F5800EF; Wed, 30 Mar 2016 00:04:47 +0200 (CEST) Subject: Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook. To: Ulrich Weigand References: <20160329181849.A8017C9C7@oc7340732750.ibm.com> Cc: gdb-patches@sourceware.org From: =?UTF-8?Q?Marcin_Ko=c5=9bcielnicki?= Message-ID: <56FAFBFE.70005@0x04.net> Date: Tue, 29 Mar 2016 22:04: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: <20160329181849.A8017C9C7@oc7340732750.ibm.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg00543.txt.bz2 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? 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. > > Bye, > Ulrich >