[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 --- Comment #6 from Maciej W. Rozycki --- Thanks WRT Ada clarification. Otherwise I don't think there's anything stopping a language definition from requiring an attempt to modify read-only data to be trapped as an exceptional condition, leaving it up to the implementation as to whether to use a hardware feature if available, or whether to rely purely on software mechanisms, such as manually validating pointers to ensure they refer to a location within the boundaries of a memory region designated for writable data before any dereference for the purpose of a write. For example the Linux kernel while it still supported the original 80386 processor used to manually validate kernel write accesses to user pages, because crippled hardware would not trap on kernel writes to read-only pages (this limitation was lifted with the CR0.WP bit from the 80486 on). >From the Linux user ABI's point of view the solution was transparent.
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2020-06-28 --- Comment #5 from Eric Botcazou --- > Regardless, I think run-time enforcement of the immutability of constant > data is important for some use cases and possibly even required by some > programming languages (Ada?). No, not in Ada, and I don't really see how this could be done as languages are usually specified in terms of an abstract machine; it's pure ABI stuff.
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 --- Comment #4 from Maciej W. Rozycki --- Sigh, I keep forgetting we don't have PC-relative memory access machine instructions. We could have had base=x0 encodings allocated for that, which are otherwise of rather limited use. Regardless, I think run-time enforcement of the immutability of constant data is important for some use cases and possibly even required by some programming languages (Ada?).
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 --- Comment #3 from Jim Wilson --- People have asked about constant pools before, but as far as I know no one has tried to implement support for them yet. We don't have a pc-relative load, so it would be a two instruction sequence with auipc. Unless maybe you load the base address into a register, which is probably OK for rvi but may cause register pressure problems for rve. We have a 12-bit signed offset, +/-2K which limits the range we can address if you want to put the base address in a register. There could also complications with the aggressive link time code relaxations that we do, depending on where you put the constant pools and how you use them. It isn't clear if constant pools are better or worse than what we already have.
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 --- Comment #2 from Maciej W. Rozycki --- I think perhaps using constant pools would be the best of both worlds?
[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95637 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #1 from Jim Wilson --- The RISC-V backend puts small read-only data in the srodata section. RISC-V is not the only target that supports srodata. I agree that this might be surprising for targets with memory protection that are expecting writes to read-only data to trap but I don't think that standards require traps here. And for targets without memory protection this is a useful code size and performance optimization. We could perhaps disable srodata support for the riscv linux and freebsd targets. I think those are the only ones with memory protection that we support. Maybe make this controlled by an option so people can choose between getting traps and getting smaller faster code.
