Fence.i tests cannot run from read-only memory

[WRansohoff]

The fence.i instruction test's self-modifying instruction is located in the .text.init section, where it seems like a program executing from ROM wouldn't be able to modify it.

Would it be possible to place the instruction which gets modified in either a dedicated memory section or under RVTEST_DATA_BEGIN, so that the linker can place it somewhere re-writable? Or is it expected that these tests will be compiled such that the .text section gets placed in memory which can be written to without any extra steps (such as unlocking Flash memory)?

Thanks for the clarification, either way.

[aswaterman]

The current expectation is that if the tests are in ROM, then the test environment must include a loader that copies the image into RAM. If this is the only test that has such a limitation, then I think modifying the test to place the instruction in .data would be acceptable. If you make a PR, we’ll review it.

On Fri, Mar 20, 2020 at 9:30 PM WRansohoff notifications@github.com wrote:

The fence.i instruction test's self-modifying instruction is located in the .text.init section, where it seems like a program executing from ROM wouldn't be able to modify it.

Would it be possible to place the instruction which gets modified in either a dedicated memory section or under RVTEST_DATA_BEGIN, so that the linker can place it somewhere re-writable? Or is it expected that these tests will be compiled such that the .text section gets placed in memory which can be written to without any extra steps (such as unlocking Flash memory)?

Thanks for the clarification, either way.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-tests/issues/268, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAH3XQRT4RXFWZDSTTNCFALRIQ7HFANCNFSM4LQZCVBA .

[WRansohoff]

I see, that makes sense - thank you.

I'll see if I can make a small change to get this test running from Flash on a GD32VF103 as an example, and close this issue in a few days if I can't. At the moment, I can see the behavior that I'm describing when I step through this test in a debugger:

(gdb) si
24  fence.i
(gdb) si
26  1: addi a3, a3, 222
(gdb) si
test_2 () at ./fence_i.S:27
27  TEST_CASE( 2, a3, 444, nop )
(gdb) i r
ra             0x0  0x0
sp             0x0  0x0
gp             0x0  0x0
tp             0x0  0x0
t0             0x80001c8    134218184
t1             0x0  0
t2             0x0  0
fp             0x0  0x0
s1             0x0  0
a0             0xffffd800   -10240
a1             0x5b8    1464
a2             0x0  0
a3             0x14d    333
[...other registers...]
pc             0x80001d8    0x80001d8 <test_2>

It seems reasonable to expect a microcontroller to load these tests into RAM, and I don't want to change the meaning of a 'known-good' test. But it would be nice to be able to run these 'first stage' tests without requiring extra setup, so thanks for entertaining the idea. I'll see if I can come up with something.

[WRansohoff]

Okay, I wrote a small change which moves the to-be-modified ADDI instructions into the .data section, and it seems to work, although I don't have many platforms or configurations to test it on:

https://github.com/riscv/riscv-tests/pull/269

[aswaterman]

Closing, since #269 is resolved.

[WRansohoff]

Thank you!