Re: [PATCH 2/4 v2] IPA: Add alloc_jump_pad_buffer target hook.

Marcin Kościelnicki
2016-03-29T22:04:56Z

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
>