OpenCores
Username:
Password:

Remember me
Register

Browse

* OpenRISC 1000

Issue List
Bug on gcc-4.5.1-or32-1.0rc1 #161
Closed hekfan opened this issue almost 13 years ago
hekfan commented almost 13 years ago

This is my test program: #define NUM 32 int i; int main() { int j; int aaNUM/4; aa0 = i; for (j=0; j<NUM/4-1; ++j) aaj+1 = aaj%10; j = aaNUM/4-1; return j; }

I compile it using "or32-elf-gcc.exe -O2 -o try.s -S try.c". The problem is: 00000000 <main>: 0: 18 60 00 00 l.movhi r3,0x0 4: d7 e1 17 f4 l.sw 0xfffffff4(r1),r2 8: d7 e1 77 f8 l.sw 0xfffffff8(r1),r14 c: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 10: a8 63 21 b0 l.ori r3,r3,0x21b0 14: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 <== r2, r14, r9's values stored in stack will be modified, if an interrupt occurs before this instruction. 18: 84 63 00 00 l.lwz r3,0x0(r3) 1c: 9c 41 00 04 l.addi r2,r1,0x4 20: 9d c1 00 20 l.addi r14,r1,0x20 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 9c 21 00 2c l.addi r1,r1,0x2c <== The values will be modified too, if an interrupt occurs after this instruction. 48: 85 21 ff fc l.lwz r9,0xfffffffc(r1) 4c: 84 41 ff f4 l.lwz r2,0xfffffff4(r1) 50: 44 00 48 00 l.jr r9 54: 85 c1 ff f8 l.lwz r14,0xfffffff8(r1)

And I compile it using "or32-elf-gcc.exe -O2 -mno-logue -o try.s -S try.c". Then it has another problem: 00000000 <main>: 0: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 4: d4 01 48 00 l.sw 0x0(r1),r9 \ 8: d4 01 10 04 l.sw 0x4(r1),r2 |==> r9?r2?r14 are saved with the offsets of 0, 4, and 8 c: d4 01 70 08 l.sw 0x8(r1),r14 / 10: 18 60 00 00 l.movhi r3,0x0 14: 9c 41 00 04 l.addi r2,r1,0x4 <== Array aa uses offset 0 too. (And 4 is the offset of aa1) 18: a8 63 21 b0 l.ori r3,r3,0x21b0 1c: 9d c1 00 20 l.addi r14,r1,0x20 20: 84 63 00 00 l.lwz r3,0x0(r3) 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 <== This instruction will modify values of r2 and r14 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 85 21 00 00 l.lwz r9,0x0(r1) 48: 84 41 00 04 l.lwz r2,0x4(r1) 4c: 85 c1 00 08 l.lwz r14,0x8(r1) 50: 44 00 48 00 l.jr r9 54: 9c 21 00 2c l.addi r1,r1,0x2c

So, we can't use the option -mno-logue. We can't use -mlogue too, when interrupt system is necessary.

hekfan commented almost 13 years ago

What happen to newline? Try one more time:

This is my test program: #define NUM 32 int i; int main() { int j; int aaNUM/4; aa0 = i; for (j=0; j<NUM/4-1; ++j) aaj+1 = aaj%10; j = aaNUM/4-1; return j; }

I compile it using "or32-elf-gcc.exe -O2 -o try.s -S try.c". The problem is: 00000000 <main>: 0: 18 60 00 00 l.movhi r3,0x0 4: d7 e1 17 f4 l.sw 0xfffffff4(r1),r2 8: d7 e1 77 f8 l.sw 0xfffffff8(r1),r14 c: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 10: a8 63 21 b0 l.ori r3,r3,0x21b0 14: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 <== r2, r14, r9's values stored in stack will be modified, if an interrupt occurs before this instruction. 18: 84 63 00 00 l.lwz r3,0x0(r3) 1c: 9c 41 00 04 l.addi r2,r1,0x4 20: 9d c1 00 20 l.addi r14,r1,0x20 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 9c 21 00 2c l.addi r1,r1,0x2c <== The values will be modified too, if an interrupt occurs after this instruction. 48: 85 21 ff fc l.lwz r9,0xfffffffc(r1) 4c: 84 41 ff f4 l.lwz r2,0xfffffff4(r1) 50: 44 00 48 00 l.jr r9 54: 85 c1 ff f8 l.lwz r14,0xfffffff8(r1)

And I compile it using "or32-elf-gcc.exe -O2 -mno-logue -o try.s -S try.c". Then it has another problem: 00000000 <main>: 0: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 4: d4 01 48 00 l.sw 0x0(r1),r9 \ 8: d4 01 10 04 l.sw 0x4(r1),r2 |==> r9?r2?r14 are saved with the offsets of 0, 4, and 8 c: d4 01 70 08 l.sw 0x8(r1),r14 / 10: 18 60 00 00 l.movhi r3,0x0 14: 9c 41 00 04 l.addi r2,r1,0x4 <== Array aa uses offset 0 too. (And 4 is the offset of aa1) 18: a8 63 21 b0 l.ori r3,r3,0x21b0 1c: 9d c1 00 20 l.addi r14,r1,0x20 20: 84 63 00 00 l.lwz r3,0x0(r3) 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 <== This instruction will modify values of r2 and r14 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 85 21 00 00 l.lwz r9,0x0(r1) 48: 84 41 00 04 l.lwz r2,0x4(r1) 4c: 85 c1 00 08 l.lwz r14,0x8(r1) 50: 44 00 48 00 l.jr r9 54: 9c 21 00 2c l.addi r1,r1,0x2c

So, we can't use the option -mno-logue. We can't use -mlogue too, when interrupt system is necessary.

jeremybennett commented almost 13 years ago
<p> Hi KF He </p> <p> You fell foul of the bugtracker formatter. It tries to guess if it is seeing HTML, and format accordingly. I've resubmitted for you, putting in explicit HTML. </p> <p> Don't worry - this will all be fixed in a day or two! </p> <p> This is my test program: <ul><pre> #define NUM 32 int i; int main() { int j; int aa[NUM/4]; aa[0] = i; for (j=0; j<NUM/4-1; ++j) aa[j+1] = aa[j]%10; j = aa[NUM/4-1]; return j; } </pre></ul> <p> I compile it using "or32-elf-gcc.exe -O2 -o try.s -S try.c". The problem is: </p> <ul><pre> 00000000 <main>: 0: 18 60 00 00 l.movhi r3,0x0 4: d7 e1 17 f4 l.sw 0xfffffff4(r1),r2 8: d7 e1 77 f8 l.sw 0xfffffff8(r1),r14 c: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 10: a8 63 21 b0 l.ori r3,r3,0x21b0 14: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 <== r2, r14, r9's values stored in stack will be modified, if an interrupt occurs before this instruction. 18: 84 63 00 00 l.lwz r3,0x0(r3) 1c: 9c 41 00 04 l.addi r2,r1,0x4 20: 9d c1 00 20 l.addi r14,r1,0x20 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 9c 21 00 2c l.addi r1,r1,0x2c <== The values will be modified too, if an interrupt occurs after this instruction. 48: 85 21 ff fc l.lwz r9,0xfffffffc(r1) 4c: 84 41 ff f4 l.lwz r2,0xfffffff4(r1) 50: 44 00 48 00 l.jr r9 54: 85 c1 ff f8 l.lwz r14,0xfffffff8(r1) </pre></ul> <p> And I compile it using "or32-elf-gcc.exe -O2 -mno-logue -o try.s -S try.c". Then it has another problem: </p> <pre><ul> 00000000 <main>: 0: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 4: d4 01 48 00 l.sw 0x0(r1),r9 \ 8: d4 01 10 04 l.sw 0x4(r1),r2 |==> r9?r2?r14 are saved with the offsets of 0, 4, and 8 c: d4 01 70 08 l.sw 0x8(r1),r14 / 10: 18 60 00 00 l.movhi r3,0x0 14: 9c 41 00 04 l.addi r2,r1,0x4 <== Array aa uses offset 0 too. (And 4 is the offset of aa[1]) 18: a8 63 21 b0 l.ori r3,r3,0x21b0 1c: 9d c1 00 20 l.addi r14,r1,0x20 20: 84 63 00 00 l.lwz r3,0x0(r3) 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 <== This instruction will modify values of r2 and r14 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 85 21 00 00 l.lwz r9,0x0(r1) 48: 84 41 00 04 l.lwz r2,0x4(r1) 4c: 85 c1 00 08 l.lwz r14,0x8(r1) 50: 44 00 48 00 l.jr r9 54: 9c 21 00 2c l.addi r1,r1,0x2c </pre></ul> <p> So, we can't use the option -mno-logue. We can't use -mlogue too, when interrupt system is necessary. </p>
hekfan commented almost 13 years ago

I'm sorry for the dos newline.

This is my test program: #define NUM 32 int i; int main() { int j; int aaNUM/4; aa0 = i; for (j=0; j<NUM/4-1; ++j) aaj+1 = aaj%10; j = aaNUM/4-1; return j; }

I compile it using "or32-elf-gcc.exe -O2 -o try.s -S try.c". The problem is: 00000000 <main>: 0: 18 60 00 00 l.movhi r3,0x0 4: d7 e1 17 f4 l.sw 0xfffffff4(r1),r2 8: d7 e1 77 f8 l.sw 0xfffffff8(r1),r14 c: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 10: a8 63 21 b0 l.ori r3,r3,0x21b0 14: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 <== r2, r14, r9's values stored in stack will be modified, if an interrupt occurs before this instruction. 18: 84 63 00 00 l.lwz r3,0x0(r3) 1c: 9c 41 00 04 l.addi r2,r1,0x4 20: 9d c1 00 20 l.addi r14,r1,0x20 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 9c 21 00 2c l.addi r1,r1,0x2c <== The values will be modified too, if an interrupt occurs after this instruction. 48: 85 21 ff fc l.lwz r9,0xfffffffc(r1) 4c: 84 41 ff f4 l.lwz r2,0xfffffff4(r1) 50: 44 00 48 00 l.jr r9 54: 85 c1 ff f8 l.lwz r14,0xfffffff8(r1)

And I compile it using "or32-elf-gcc.exe -O2 -mno-logue -o try.s -S try.c". Then it has another problem: 00000000 <main>: 0: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 4: d4 01 48 00 l.sw 0x0(r1),r9 \ 8: d4 01 10 04 l.sw 0x4(r1),r2 |==> r9, r2, r14 are saved with the offsets of 0, 4, and 8 c: d4 01 70 08 l.sw 0x8(r1),r14 / 10: 18 60 00 00 l.movhi r3,0x0 14: 9c 41 00 04 l.addi r2,r1,0x4 <== Array aa uses offset 0 too. (And 4 is the offset of aa1) 18: a8 63 21 b0 l.ori r3,r3,0x21b0 1c: 9d c1 00 20 l.addi r14,r1,0x20 20: 84 63 00 00 l.lwz r3,0x0(r3) 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 <== This instruction will modify values of r2 and r14 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 85 21 00 00 l.lwz r9,0x0(r1) 48: 84 41 00 04 l.lwz r2,0x4(r1) 4c: 85 c1 00 08 l.lwz r14,0x8(r1) 50: 44 00 48 00 l.jr r9 54: 9c 21 00 2c l.addi r1,r1,0x2c

So, we can't use the option -mno-logue. We can't use -mlogue too, when interrupt system is necessary.

jeremybennett was assigned almost 13 years ago
hekfan commented almost 13 years ago

I'm sorry for the dos newline.

This is my test program: #define NUM 32 int i; int main() { int j; int aaNUM/4; aa0 = i; for (j=0; j<NUM/4-1; ++j) aaj+1 = aaj%10; j = aaNUM/4-1; return j; }

I compile it using "or32-elf-gcc.exe -O2 -o try.s -S try.c". The problem is: 00000000 <main>: 0: 18 60 00 00 l.movhi r3,0x0 4: d7 e1 17 f4 l.sw 0xfffffff4(r1),r2 8: d7 e1 77 f8 l.sw 0xfffffff8(r1),r14 c: d7 e1 4f fc l.sw 0xfffffffc(r1),r9 10: a8 63 21 b0 l.ori r3,r3,0x21b0 14: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 <== r2, r14, r9's values stored in stack will be modified, if an interrupt occurs before this instruction. 18: 84 63 00 00 l.lwz r3,0x0(r3) 1c: 9c 41 00 04 l.addi r2,r1,0x4 20: 9d c1 00 20 l.addi r14,r1,0x20 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 9c 21 00 2c l.addi r1,r1,0x2c <== The values will be modified too, if an interrupt occurs after this instruction. 48: 85 21 ff fc l.lwz r9,0xfffffffc(r1) 4c: 84 41 ff f4 l.lwz r2,0xfffffff4(r1) 50: 44 00 48 00 l.jr r9 54: 85 c1 ff f8 l.lwz r14,0xfffffff8(r1)

And I compile it using "or32-elf-gcc.exe -O2 -mno-logue -o try.s -S try.c". Then it has another problem: 00000000 <main>: 0: 9c 21 ff d4 l.addi r1,r1,0xffffffd4 4: d4 01 48 00 l.sw 0x0(r1),r9 \ 8: d4 01 10 04 l.sw 0x4(r1),r2 |==> r9, r2, r14 are saved with the offsets of 0, 4, and 8 c: d4 01 70 08 l.sw 0x8(r1),r14 / 10: 18 60 00 00 l.movhi r3,0x0 14: 9c 41 00 04 l.addi r2,r1,0x4 <== Array aa uses offset 0 too. (And 4 is the offset of aa1) 18: a8 63 21 b0 l.ori r3,r3,0x21b0 1c: 9d c1 00 20 l.addi r14,r1,0x20 20: 84 63 00 00 l.lwz r3,0x0(r3) 24: 04 00 00 0d l.jal 58 <__modsi3> 28: 9c 80 00 0a l.addi r4,r0,0xa 2c: d4 02 58 00 l.sw 0x0(r2),r11 <== This instruction will modify values of r2 and r14 30: 9c 42 00 04 l.addi r2,r2,0x4 34: e4 22 70 00 l.sfne r2,r14 38: 13 ff ff fb l.bf 24 <main+0x24> 3c: a8 6b 00 00 l.ori r3,r11,0x0 40: 85 61 00 1c l.lwz r11,0x1c(r1) 44: 85 21 00 00 l.lwz r9,0x0(r1) 48: 84 41 00 04 l.lwz r2,0x4(r1) 4c: 85 c1 00 08 l.lwz r14,0x8(r1) 50: 44 00 48 00 l.jr r9 54: 9c 21 00 2c l.addi r1,r1,0x2c

So, we can't use the option -mno-logue. We can't use -mlogue too, when interrupt system is necessary.

jeremybennett commented almost 13 years ago
<p> Hi KF He </p> <p> I suggest for now you surround your entire submission by <pre> and </pre> to avoid formatting problems. </p> <p> This is not a bug. The ABI requires any interrupt handler not to touch the first 128 bytes of stack (the "red zone"), so your data on the stack will be perfectly safe. </p> <p> There is an option to specify a smaller redzone, or even eliminate it altogether, -mredzone=<size>. However this will lead to less efficient code. Much better to write interrupt handlers that properly recognize the ABI specification. </p> <p> Marking closed. </p> <p> Jeremy </p>
jeremybennett commented almost 13 years ago
<p> That should have read surround by &lt;pre&gt; and &lt;/pre&gt;. </p>
jeremybennett closed this almost 13 years ago
hekfan commented almost 13 years ago
<p>Thank you. Now I see what's redzone.</p> <p>But what can I do to write an interrupt handler?</p> <p>In the function "or32_compute_frame_size", I see</p> <hr> <p>bool interrupt_p = false;</p> <p>...</p> <p>frame_info.gpr_frame = interrupt_p ? or32_redzone : 0;</p> <hr> <p>And I can't find any __attribute about interrupt.</p> <p>It seems that redzone is unprotected yet.</p>
jeremybennett commented almost 13 years ago
<p> Hi KF He </p> <p> All interrupts come in via exception vector 0x800. Under Linux, I believe that does the necessary stack and register manipulation. If you are writing your own bare metal code, you will need to provide this. </p> <p> It would be useful to support the interrupt attribute. Perhaps you would record a feature request for this. </p> <p> HTH </p> <p> Jeremy </p>
Assignee
jeremybennett
Labels
Bug
© copyright 1999-2018 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.