Actual immutability enforcement by placing immutable data into read-only sections

[bauss]

On Monday, 19 December 2022 at 12:13:08 UTC, Siarhei Siamashka 
wrote:
> Right now D compilers place string literals into a read-only 
> section, but most of the other types of `static immutable` data 
> have no protection against rogue writes.
>
> https://forum.dlang.org/post/cmtaeuedmdwxjecpcrjh@forum.dlang.org is an example of a non-obvious case of immutable data corruption. What's happening there is that [druntime modifies](https://github.com/dlang/dmd/blob/v2.101.1/druntime/src/rt/deh.d#L46) the static immutable instance of Exception when throwing it.
>
> The old bugreport 
> https://issues.dlang.org/show_bug.cgi?id=12118 is also related 
> to throwing an immutable Exception, but the corruption is done 
> by the user code in the catch block.
>
> Troubleshooting such problems would have been so much easier if 
> immutable objects were actually placed in a read-only section 
> and any write attempts triggered segfaults at runtime. I think 
> that [bare metal code for 
> microcontrollers](https://forum.dlang.org/post/rkrpdgjnhwdysqnnbslf@forum.dlang.org) could also potentially benefit from this, because this would enable placing immutable data generated by CTFE into NOR flash instead of wasting SRAM space.
>
> What do you think about it? Does this require a new DIP?

Isn't it going to be difficult to properly implement? Since you 
can't really place data into read-only memory, but you have to 
protect whole pages ex. VirtualProtect() on Windows. Esepcially 
with how immutable data can still be allocated through GC. Or am 
I not understanding something about this at all?