[Bug middle-end/25521] change semantics of const volatile variables

["jose.marchesi at oracle dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25521

Jose E. Marchesi <jose.marchesi at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jose.marchesi at oracle dot com

--- Comment #6 from Jose E. Marchesi <jose.marchesi at oracle dot com> ---
So I am being bitten by this in the BPF backend [1].

Long story short: LLVM places initialized `volatile const' variables in
.rodata, whereas GCC puts them in .data.

The kernel's libbpf scans the objects and generates a "skeleton" header that,
among other things, reflects the sections in the compiled BPF object.  This
divergence in behavior between LLVM and GCC makes the skeleton to define
different data structures, i.e. obj->rodata->foo vs. obj->data->foo.  See [1]
for details.

I don't actually understand Gabriel's comment, "If it may be modified by
hardware or other external means, it can't go into .rodata section.".  Why not?
 The permissions of the .rodata section eventually determines the permissions
used to map the corresponding pages in the particular process running the
program, but I don't see how can prevent the same physical memory to be updated
by hardware, or even other processes mapping the same physical page using write
perms.

Or what am I missing?  Can we change the behavior of GCC to put such variables
in .rodata?

[1]
https://lore.kernel.org/bpf/87fsj8vjcy.fsf@oracle.com/T/#me726127e166f97fd50f09b647a604f176f809c63