Re: [PATCH 1/3] x86: Add CPU Vendor ID detection support for Zhaoxin processors

[Florian Weimer <fw at deneb dot enyo dot de>]

* May Shao:

> On 09/12/2019 4:34 pm, Florian Weimer wrote:
>> * MayShao:
>>
>>> +                 cpu_features->feature[index_arch_Slow_SSE4_2]
>>> +                   |= (bit_arch_Slow_SSE4_2
>>> +                   | bit_arch_Prefer_MAP_32BIT_EXEC);
>>
>> Is the Prefer_MAP_32BIT_EXEC part really correct?
>
> As glibc comments for this macro below:
>
> "For 64-bit applications, branch prediction performance may be
> negatively impacted when the target of a branch is more than
> 4GB away from the branch"
>
> We have analyzed this generation of processors and found it have
> this issue in theory, so we add this flag for it.

I think this flag was added for processors which cannot predict the
target of indirect calls if it is more than 4 GiB (or was it 2 GiB)
away from the current program counter.  

>> As discussed recently, it does not have an effect with programs linked
>> with -z separate-code (the default these days, I think) and PIE.
>
> Do you mean the above macro will be ignored if program linked
> with -z separate-code and PIE?

If it is linked with -z separate-code, it will be ignored because the
first load segment does not have the execute bit set, so the mmap
wrapper does not add the MAP_32BIT flag.

With PIE and without -z separate-code, you get worse performance
because the dynamic loader is mapped at some 0x7f… address, the main
program is mapped at 0x55…, and all the shared objects will be mapped
at 0x00… due to MAP_32BIT.

> If it does, is there any harms if keep this macro? thanks a lot!

Yes, I think it's not very useful in its currently implementation and
should probably be removed.

A real fix will need kernel support, to map everything (dynamic
loader, main program, shared objects) closely together.