sim: or1k: Eliminate dangerous RWX load segments
authorStafford Horne <shorne@gmail.com>
Sat, 19 Aug 2023 07:30:54 +0000 (08:30 +0100)
committerStafford Horne <shorne@gmail.com>
Thu, 24 Aug 2023 06:03:48 +0000 (07:03 +0100)
This fixes test failures caused by the new linker warning which report:

  ./ld/ld-new: warning: load.S.x has a LOAD segment with RWX permissions

Fix this by splitting the linker MEMORY into ram and rom to avoid
generating RWX sections.  This required tests to be adjusted to fix
issues with the move.  Namely:

  - fpu tests: were incorrectly using l.ori with ha(anchor) which now
    that we pushed the anchor up in memory it exposes the bug.  Update
    to used the correct l.movhi instruction instead.
  - adrp test: the test reports ram offset addresses, now that we have
    moved memory layout around a bit I adjusted the test output.  Some
    padding is added before pi to show that the actual address of pi and
    the adrp page offset are not the same.

Bug: https://sourceware.org/PR29957

sim/testsuite/or1k/adrp.S
sim/testsuite/or1k/fpu-unordered.S
sim/testsuite/or1k/fpu64a32-unordered.S
sim/testsuite/or1k/fpu64a32.S
sim/testsuite/or1k/or1k-test.ld

index eaddcb0388568429c2925089d9ff998589008c55..192324c698e0582a51cc4267191e269053255c28 100644 (file)
@@ -17,9 +17,9 @@
 
 # mach: or1k
 # output: report(0x00002064);\n
-# output: report(0x00012138);\n
+# output: report(0x0001a008);\n
 # output: report(0x00002000);\n
-# output: report(0x00012000);\n
+# output: report(0x0001a000);\n
 # output: report(0x00002000);\n
 # output: report(0x00014000);\n
 # output: report(0x00000000);\n
@@ -32,6 +32,7 @@
        .section .data
        .org 0x10000
        .align 4
+pad:   .quad   0
        .type   pi, @object
        .size   pi, 4
 pi:
index 624aa0fe05dd0e914cd14d9ce8c2adf7e09b0a60..a89172e37afa0f5d4d8467a353fa7b610b69e923 100644 (file)
@@ -57,7 +57,7 @@ start_tests:
         *  r13  e   as float
         *  r16  nan as float
         */
-       l.ori   r11, r0, ha(anchor)
+       l.movhi r11, ha(anchor)
        l.addi  r11, r11, lo(anchor)
        l.lwz   r12, 0(r11)
 
index e0ae6e770d15b295d34136a3f3d3ef867737cc6d..51d915e4e75fb544bdb5692af947ab392e69084c 100644 (file)
@@ -58,7 +58,7 @@ start_tests:
         *  r14,r15  e   as double
         *  r16,r17  nan as double
         */
-       l.ori   r11, r0, ha(anchor)
+       l.movhi r11, ha(anchor)
        l.addi  r11, r11, lo(anchor)
        l.lwz   r12, 0(r11)
        l.lwz   r13, 4(r11)
index 71b72b7761cd96315628624cd1edfa9eaeae42c6..6ea60b28cf2958607dcbf4b7c484cd20973c8773 100644 (file)
@@ -98,7 +98,7 @@ start_tests:
         *  r14,r15  e  as double
         *  r16,r17  a long long
         */
-       l.ori   r11, r0, ha(anchor)
+       l.movhi r11, ha(anchor)
        l.addi  r11, r11, lo(anchor)
        l.lwz   r12, 0(r11)
        l.lwz   r13, 4(r11)
index f1535daeabd4483c63f9ac8fa0b0d9de8b62b7b6..c26ecaf3f23cec094744c4b7865d817730c6be51 100644 (file)
@@ -20,8 +20,9 @@ MEMORY
     /* The exception vectors actually start at 0x100, but if you specify
        that address here, the "--output-target binary" step will start from
        address 0 with the contents meant for address 0x100.  */
-    exception_vectors : ORIGIN =  0 , LENGTH = 8K
-    ram               : ORIGIN =  8K, LENGTH = 2M - 8K
+    exception_vectors : ORIGIN =  0 , LENGTH =  8K
+    rom               : ORIGIN =  8K, LENGTH = 40K
+    ram               : ORIGIN = 40K, LENGTH =  2M - 40K
 }
 
 SECTIONS
@@ -37,7 +38,7 @@ SECTIONS
        *(.text.*)
        *(.rodata)
        *(.rodata.*)
-    } > ram
+    } > rom
 
     .data :
     {