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

["Koning, Paul" <Paul.Koning@dell.com>]

> 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