On Mon, Jan 8, 2018 at 3:37 AM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Sun, Jan 7, 2018 at 8:07 PM, Sandra Loosemore
> <san...@codesourcery.com> wrote:
>> On 01/07/2018 03:58 PM, H.J. Lu wrote:
>>>
>>> This set of patches for GCC 8 mitigates variant #2 of the speculative
>>> execution
>>> vulnerabilities on x86 processors identified by CVE-2017-5715, aka
>>> Spectre. They
>>> convert indirect branches to call and return thunks to avoid speculative
>>> execution
>>> via indirect call and jmp.
>>
>>
>> I have a general documentation issue with all the new command-line options
>> and attributes added by this patch set: the documentation is very
>> implementor-speaky and doesn't explain what user-level problem they're
>> trying to solve.
>
> Do you have any suggestions?
>
>> E.g. to take just one example
>>
>>> +@item function_return("@var{choice}")
>>> +@cindex @code{function_return} function attribute, x86
>>> +On x86 targets, the @code{function_return} attribute causes the compiler
>>> +to convert function return with @var{choice}. @samp{keep} keeps function
>>> +return unmodified. @samp{thunk} converts function return to call and
>>> +return thunk. @samp{thunk-inline} converts function return to inlined
>>> +call and return thunk. @samp{thunk-extern} converts function return to
>>> +external call and return thunk provided in a separate object file.
>>
>>
>> Why would you want to mess with call and return code generation in this way?
>> The documentation doesn't say.
>>
>> For thunk-extern, is the programmer supposed to provide the thunk? How
>> would you go about implementing the missing bit of code? What should it do?
>> I'm compiler implementor and I wouldn't even know how to use this feature by
>> reading the manual; how would an ordinary application programmer who isn't
>> familiar with GCC internals know how to use it?
That is the best I can do. My GCC documentation describes what my
patches generate. The usage guidance should come from Intel white paper.
After it is published, I will submit a GCC patch to refer it. It will
be very nice
for Intel white paper to recommend what compiler options should be used.
> This option was requested by Linux kernel people. Linux kernel may
> choose different thunks at kernel load-time. If a program doesn't know
> how to write external thunk, he/she shouldn't it.
>
>> If the goal here is to tell GCC to produce code that is protected against
>> the Spectre vulnerability, perhaps simplify this to adding just one option
>> that controls all the things you've given separate options and attributes
>> for?
>
> -mindirect-branch=thunk does the job. Other options/choices are for
> fine tuning.
>
> Thanks.
>
> --
> H.J.
--
H.J.
