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

Eli Friedman via cfe-dev cfe-dev at lists.llvm.org
Thu Jan 10 12:06:55 PST 2019


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/20190110/c4e15cc7/attachment.html>


More information about the cfe-dev mailing list