This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook.
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: koriakin at 0x04 dot net (Marcin KoÅcielnicki)
- Cc: gdb-patches at sourceware dot org, koriakin at 0x04 dot net (Marcin KoÅcielnicki)
- Date: Tue, 29 Mar 2016 20:18:49 +0200 (CEST)
- Subject: Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook.
- Authentication-results: sourceware.org; auth=none
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