Re: [PATCH V2] place `const volatile' objects in read-only sections

[Koning, Paul via Gcc-patches]

> On Sep 27, 2022, at 8:51 PM, Jeff Law via Gcc-patches 
> <gcc-patches@gcc.gnu.org> wrote:
> 
> 
> On 8/5/22 05:41, Jose E. Marchesi via Gcc-patches wrote:
>> [Changes from V1:
>> - Added a test.]
>> 
>> It is common for C BPF programs to use variables that are implicitly
>> set by the BPF loader and run-time.  It is also necessary for these
>> variables to be stored in read-only storage so the BPF verifier
>> recognizes them as such.  This leads to declarations using both
>> `const' and `volatile' qualifiers, like this:
>> 
>>   const volatile unsigned char is_allow_list = 0;
>> 
>> Where `volatile' is used to avoid the compiler to optimize out the
>> variable, or turn it into a constant, and `const' to make sure it is
>> placed in .rodata.
>> 
>> Now, it happens that:
>> 
>> - GCC places `const volatile' objects in the .data section, under the
>>   assumption that `volatile' somehow voids the `const'.
>> 
>> - LLVM places `const volatile' objects in .rodata, under the
>>   assumption that `volatile' is orthogonal to `const'.
>> ...
> 
> The best use I've heard for const volatile is stuff like hardware status 
> registers which are readonly from the standpoint of the compiler, but which 
> are changed by the hardware.   But for those, we're looking for the const to 
> trigger compiler diagnostics if we try to write the value.  The volatile (of 
> course) indicates the value changes behind our back.

I'd go a bit further and say that this is the only use of const volatile that 
makes any sense.

> What you're trying to do seems to parallel that case reasonably well for the 
> volatile aspect.  You want to force the compiler to read the data for every 
> access.
> 
> Your need for the const is a bit different.  Instead of looking to get a 
> diagnostic out of the compiler if its modified, you need the data to live in 
> .rodata so the BPF verifier knows the compiler/code won't change the value.  
> Presumably the BPF verifier can't read debug info to determine the const-ness.
> 
> I'm not keen on the behavior change, but nobody else is stepping in to review 
> and I don't have a strong case to reject.  So OK for the trunk.

A const volatile that sits in memory feels like a programmer error.  Instead of 
worrying about how it's handled, would it not make more sense to tag it with a 
warning?

        paul