https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89269
Pharos Team <rtos.pharos at outlook dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from Pharos Team <rtos.pharos at outlook dot com> ---
I'm sorry but your comment is invalid. The following lines:
800013b4: 00bff797 auipc a5,0xbff
800013b8: 04c78793 addi a5,a5,76 #80c00400
<partition1BssEnd>
800013bc: 639c ld a5,0(a5)
load to a5 the address of partition1BssEnd and then they "read" the location of
partition1BssEnd. Even though there is no "write", the "read" operation is
triggering the MMU to raise an error (as it should).
For example, compiling the same C code for ARM AARCH64 we get the result:
1448: a9be7bfd stp x29, x30, [sp, #-32]!
144c: 910003fd mov x29, sp
PharosHwQueueSendR sendResult;
//uint8_t message4[10];
uint8_t message[] = {
1450: 128004a0 mov w0, #0xffffffda // #-38
1454: 390043e0 strb w0, [sp, #16]
1458: 528009e0 mov w0, #0x4f // #79
145c: 390047e0 strb w0, [sp, #17]
1460: 128007a0 mov w0, #0xffffffc2 // #-62
1464: 39004be0 strb w0, [sp, #18]
1468: 52800080 mov w0, #0x4 // #4
146c: 39004fe0 strb w0, [sp, #19]
1470: 528000a0 mov w0, #0x5 // #5
1474: 390053e0 strb w0, [sp, #20]
1478: 528000c0 mov w0, #0x6 // #6
147c: 390057e0 strb w0, [sp, #21]
1480: 528000e0 mov w0, #0x7 // #7
1484: 39005be0 strb w0, [sp, #22]
1488: 52800100 mov w0, #0x8 // #8
148c: 39005fe0 strb w0, [sp, #23]
That is, everything is placed (correctly) on the stack. I just place the
aarch64 example so that we can make sure that the C code is not making any
reference at all to partition1BssEnd (I have no idea why on RISC-V it would
make such a reference).
With this "read" problem I took the liberty to reopen the bug. I truly believe
this is a bug and not invalid.
Best regards,
Pharos team
