Anton Blanchard <an...@samba.org> writes:
>> We added:
>>
>> BUILD_BUG_ON(!__builtin_constant_p(feature))
>>
>> to cpu_has_feature() and mmu_has_feature() in order to catch usage
>> issues (such as cpu_has_feature(cpu_has_feature(X)). Unfortunately
>> LLVM isn't smart enough to resolve this, and it errors out.
>>
>> I work around it in my clang/LLVM builds of the kernel, but I have
>> just discovered that it causes a lot of issues for the bcc (eBPF)
>> trace tool (which uses LLVM).
>>
>> How should we work around this? Wrap the checks in !clang perhaps?
>
> Looks like it's a weakness in LLVM with inlining:
>
> #include <assert.h>
>
> #if 1
> static inline void foo(unsigned long x)
> {
> assert(__builtin_constant_p(x));
> }
> #else
> #define foo(X) assert(__builtin_constant_p(X))
> #endif
>
> int main(void)
> {
> foo(1);
>
> return 0;
> }
OK. cpu_has_feature() is __always_inline:
static __always_inline bool cpu_has_feature(unsigned long feature)
{
int i;
BUILD_BUG_ON(!__builtin_constant_p(feature));
But I guess even that doesn't work?
Hmm, in fact it seems because we don't define
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING and CONFIG_OPTIMIZE_INLINING, we
get:
#define inline inline __attribute__((always_inline)) notrace
So in fact every inline function is marked always_inline all the time,
which seems dubious.
But still, it seems clang is ignoring always_inline.
cheers
