[Bug target/95637] New: Read-only data assigned to `.sdata' rather than `.rodata'

[Bug target/95637] New: Read-only data assigned to `.sdata' rather than `.rodata'

[macro@linux-mips.org]

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

            Bug ID: 95637
           Summary: Read-only data assigned to `.sdata' rather than
                    `.rodata'
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: macro@linux-mips.org
  Target Milestone: ---
            Target: riscv*-*-linux-gnu

As observed in PR fortran/95631 read-only data gets assigned to `.sdata'
rather than `.rodata', which in turn causes invalid attempts to modify it
not to be trapped at run time.

A test case from the PR referred is:

C
C     CHANGE THE VALUE OF 4
C

      CALL INC(4)
      WRITE (*, 30) 4
30    FORMAT ('2+2=',I4)
      END

      SUBROUTINE INC(I)
      I = I + 1
      END

which is supposed to trap on the modification of literal 4 in INC.
Instead the program runs to completion and prints:

2+2=   5

I have no C language test case at hand, but I guess it does not matter,
this one is sweet and simple.

[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'

[wilson at gcc dot gnu.org]

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

Jim Wilson <wilson at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wilson at gcc dot gnu.org

--- Comment #1 from Jim Wilson <wilson at gcc dot gnu.org> ---
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.

[Bug target/95637] Read-only data assigned to `.sdata' rather than `.rodata'

[macro@linux-mips.org]

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

--- Comment #2 from Maciej W. Rozycki <macro@linux-mips.org> ---
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'

[wilson at gcc dot gnu.org]

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

--- Comment #3 from Jim Wilson <wilson at gcc dot gnu.org> ---
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'

[macro@linux-mips.org]

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

--- Comment #4 from Maciej W. Rozycki <macro@linux-mips.org> ---
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'

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> 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 <ebotcazou at gcc dot gnu.org> ---
> 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'

[LpSolit at gmail dot com]

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

--- Comment #6 from Maciej W. Rozycki <macro at orcam dot me.uk> ---
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.