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

["Marcin Kościelnicki" <koriakin@0x04.net>]

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
>