[cfe-dev] Diagnosing Incompatible Attributes Between a Calling Function and the Callee Function

[Zola Bridges via cfe-dev]

Thanks for the info! For now, I've committed the patch without the
diagnostic and will come back to it when I get some time. I'll think about
whether this diagnostic is better left out. I'm not sure if I'll decide to
not include it at all since you, as you mentioned, it would miss a lot of
major cases.

Zola Bridges


On Thu, Jan 10, 2019 at 12:06 PM Eli Friedman <efriedma at codeaurora.org>
wrote:

> On 1/10/2019 10:44 AM, Zola Bridges via cfe-dev wrote:
>
> Hi everyone,
>
>
> I'm working on adding function level Clang attributes for the Speculative
> Load Hardening (SLH) feature, so devs who know what they are doing can
> enable or disable SLH function by function. There are two attributes
> 'no_speculative_load_hardening' and 'speculative_load_hardening.'
>
>
> As a part of this, I want to diagnose a special case where a function
> marked
>
> 'no_speculative_load_hardening' will still have
> 'speculative_load_hardening' enabled.
>
>
> Whenever a function marked 'speculative_load_hardening' is inlined into
> another function, then that function that it was inlined into will have
> SLH enabled no matter what. [If you want more info on the rationale for
> this, check out the patch comments here:
> https://reviews.llvm.org/D54909?id=175599#inline-487979]
>
> I want to diagnose cases similar to this example:
>
>
> __attribute__((speculative_load_hardening)) inline int foo(int i) {
>
>
> The "inline" keyword here is basically irrelevant; we aren't required to
> inline functions marked inline, and we can inline functions which are not
> marked "inline".  (The "inline" keyword has other effects related to
> linkage, but they don't have any effect on the arguments here.)
>
> In general, it's impossible to catch all cases of a
> no_speculative_load_hardening calling a speculative_load_hardening function
> in the frontend: a no_speculative_load_hardening might call a
> speculative_load_hardening indirectly, or the callee might be in a
> different translation unit.  (The optimizer may or may not discover the
> call later, depending on the exact construct in question and the
> optimization flags.)
>
> Given that, I'm not sure your proposed diagnostic makes sense; even if you
> could diagnose constructs like your example, you'd be missing all the
> important cases.
>
> Also, if the general rule is "the optimizer may choose to perform SLH on a
> function even if it's marked no_speculative_load_hardening", you should
> probably avoid specifically mentioning inlining in the documentation, since
> it's misleading.  (Other optimizations might be affected by this rule, like
> function merging or outlining.)
>
>
> 2. Add the diagnosis to CheckFunctionCall or checkCall in SemaChecking.cpp
>
>
> Why doesn't this work?
>
> The context about the caller of the callee isn't available. I need to know
> whether the caller has the 'no_speculative_load_hardening' attribute.
>
> The context should be available; you can call
> Sema::getEnclosingFunction(), or something like that.
>
> -Eli
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190118/adc92c81/attachment.html>