Test misalign-jal-01.S generates compressed instruction for platforms that support only RV32I

Question

Test misalign-jal-01.S generates compressed instruction for platforms that support only RV32I

Closed this issue 4 months ago · 7 comments

Test is compiled using riscv32-unknown-elf-gcc -march=rv32i_zicsr -mabi=ilp32 ... and the generated instructions are:

...
0000                	.short	0x0000
00354513          	xor	a0,a0,3
00000013          	nop
0001                	.insn	2, 0x0001
00000117          	auipc	sp,0x0
02610113          	add	sp,sp,38
...

Toolchain is compiled without compressed instruction support.
This seems to be related with the alignment in LA macro:

/**** fixed length LA macro; alignment and rvc/norvc unknown before execution ****/
#define LA(reg,val)     ;\

This will fail this tests because a second exception will happen that is illegal instruction for RV32I platforms!

Answer 1 · 2024-03-12T00:50:22.000Z

hmm, I'm not sure I understand where the .short, and the .insn came from. The code turns on compressed ops (using .push, ;option rvc) in case the model implements C extension and is currently at odd alignment), then aligns the code to a 2^(2..4)B aligned address (which should insert noops), then forces norvc, implements the la reg, val pseudo op, re-aligns to a 2^2..4) boundary, and restores the original rvc/norvc status. This kind of looks like the toolchain is inserting zeroes instead of noops (which is correct if it is data... but not necessarily for *inline" code. I'm not sure how to cause .align to force noops.

…

On Mon, Mar 11, 2024 at 1:59 PM ArbnorSh ***@***.***> wrote: Test is compiled using riscv32-unknown-elf-gcc -march=rv32i_zicsr -mabi=ilp32 ... and the generated instructions are: ... 0000 .short 0x0000 00354513 xor a0,a0,3 00000013 nop 0001 .insn 2, 0x0001 00000117 auipc sp,0x0 02610113 add sp,sp,38 ... Toolchain is compiled without compressed instruction support. This seems to be related with the alignment in LA macro: /**** fixed length LA macro; alignment and rvc/norvc unknown before execution ****/ #define LA(reg,val) ;\ This will fail this tests because a second exception will happen that is illegal instruction for RV32I platforms! — Reply to this email directly, view it on GitHub <#442>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJULQJ6S3D3R6RZG2Z3YXYLMRAVCNFSM6AAAAABERBGLECVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4DAMRSGE4DGNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Answer 2 · 2024-03-12T01:28:04.000Z

OK, re-reading this: this test is deliberately causing a misaligned trap, and that branches to the trap handler. The trap handler is compiled to be all aligned, so that shouldn't happen in the handler. This must then be happening in the (only) test inside the TEST_JAL_OP. The TEST_JAL_OP macro (which is complicated with tons of conditionals and no comments) so it will take quite a bit of work to figure out what it is doing and where it is going wrong. Can you post (or send me ) a larger snippet of the compiled code, starting at label inst_0: through rvtest_code_end:: On Mon, Mar 11, 2024 at 5:50 PM Allen Baum ***@***.***> wrote:

…

hmm, I'm not sure I understand where the .short, and the .insn came from. The code turns on compressed ops (using .push, ;option rvc) in case the model implements C extension and is currently at odd alignment), then aligns the code to a 2^(2..4)B aligned address (which should insert noops), then forces norvc, implements the la reg, val pseudo op, re-aligns to a 2^2..4) boundary, and restores the original rvc/norvc status. This kind of looks like the toolchain is inserting zeroes instead of noops (which is correct if it is data... but not necessarily for *inline" code. I'm not sure how to cause .align to force noops. On Mon, Mar 11, 2024 at 1:59 PM ArbnorSh ***@***.***> wrote: > Test is compiled using riscv32-unknown-elf-gcc -march=rv32i_zicsr > -mabi=ilp32 ... and the generated instructions are: > > ... > 0000 .short 0x0000 > 00354513 xor a0,a0,3 > 00000013 nop > 0001 .insn 2, 0x0001 > 00000117 auipc sp,0x0 > 02610113 add sp,sp,38 > ... > > Toolchain is compiled without compressed instruction support. > This seems to be related with the alignment in LA macro: > > /**** fixed length LA macro; alignment and rvc/norvc unknown before execution ****/ > #define LA(reg,val) ;\ > > This will fail this tests because a second exception will happen that is > illegal instruction for RV32I platforms! > > — > Reply to this email directly, view it on GitHub > <#442>, or > unsubscribe > <https://github.com/notifications/unsubscribe-auth/AHPXVJULQJ6S3D3R6RZG2Z3YXYLMRAVCNFSM6AAAAABERBGLECVHI2DSMVQWIX3LMV43ASLTON2WKOZSGE4DAMRSGE4DGNQ> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

Answer 3 · 2024-03-12T07:52:46.000Z

Attaching the requested part as a file!
inst_0.disass.txt

Answer 4 · 2024-03-15T05:23:28.000Z

@ArbnorSh This test is deliberately causing a misaligned-fetch trap by jumping to a misaligned-address. The disass is showing you misaligned address where pc will jump in order to check that feature. Here is the complete disassembly and Sail_log file through which you can understand the behavior of the test. Let me breakdown the behavior of the test for your better understanding.

address 0x8000026c instr jal a0,80000476 is causing pc to jump to a misaligned address.
If misaligned access is enabled and DUT/Sail has compressed instruction support, then DUT/Sail will execute c.nop instruction and no exception will be thrown,
but in your case, when misaligned-access is disabled and/or compressed instruction support does not exist, then it will cause misaligned-fetch exception and will call the trap handler. You will see the following prompt in Sail log file in your case,

mem[X,0x8000026C] -> 0x056F
mem[X,0x8000026E] -> 0x20A0
[107] [M]: 0x8000026C (0x20A0056F) jal a0, 522
trapping from M to M to handle misaligned-fetch
handling exc#0x00 at priv M with tval 0x80000476
CSR mstatus <- 0x00001800
For reference => Line 645-650 (in the given log file)

Here mtval is getting 0x80000476 value showing you the misaligned address. This address is same as where you have seen .short 0x0000 or .2byte 0x0 (both are the same things).
Upon returning from the trap (or no trap in case-1), the program will keep executing instructions line by line.

Now, the address 0x80000476 is also in code region, so DUT/Sail will eventually reach to this address to execute this instruction. Over here, it will fetch a compressed instruction, if compressed instruction is supported by DUT/Sail, it will execute that c.nop instruction, otherwise (when compressed support is not there => Your case) it will cause illegal-instruction exception and once again calls the trap handler. For your case, you will see the following prompt in Sail log.

mem[X,0x80000474] -> 0x0000
[453] [M]: 0x80000474 (0x0000) c.illegal 0
trapping from M to M to handle illegal-instruction
handling exc#0x02 at priv M with tval 0x00000000
CSR mstatus <- 0x00001800
For reference => Line 2636-2641 in the given log file

In either case (trap or no trap), the program will complete its execution without any trouble, so you should be getting an exit from this program and this test will be passing on both DUT and Sail in all possible cases (with/without misaligned, with/without compressed support), so dont worry if you are seeing any compressed instruction in your disass, it is there for deliberate reason.

Answer 5 · 2024-03-15T06:27:32.000Z

Yes, this test is deliberately inserting a compressed noop ahead of a 32bit instruction to force it to be misaligned, so it can see that the core handles the misaligned up correctly. What still confuses me is that you say there is a "second exception", and I don't know which exception that would be. Normally, traps return to the instruction recorded in EPC, but the trap handler will always return to the next aligned 8byte boundary that follows the instruction at the EPC address. This guarantees that it won't get into an infinite trap loop, and also gives code the opportunity to branch to special handling code if it didn't trap (because that will be skipped over if there is a trap). Normally, tests will add 2 noops after test to ensure the return won't skip over the any non-noops upon return. This test has several different misaligned branches and jumps, both forward and backward. This is expected. So, could you be a little more clear about what error you're seeing? - Is it refusing to compile? - Are you not expecting multiple traps (there shouldn't be two back-to-back though) - Is it not matching what Sail is doing? - Or did it actually branch to an unaligned address and try to execute the compressed noop or illegal zero opcode (which it can't because it doesn't have C-extension support). That might be a bug in the DUT rather than in the test.

…

On Thu, Mar 14, 2024 at 10:23 PM Umer Shahid ***@***.***> wrote: @ArbnorSh <https://github.com/ArbnorSh> This test is deliberately causing a misaligned-fetch trap by jumping to a misaligned-address. The disass is showing you misaligned address where pc will jump in order to check that feature. Here is the complete disassembly <https://github.com/riscv-non-isa/riscv-arch-test/files/14611013/ref_disass.txt> and Sail_log file <https://github.com/riscv-non-isa/riscv-arch-test/files/14611002/misalign-jal-01.log> through which you can understand the behavior of the test. Let me breakdown the behavior of the test for your better understanding. address 0x8000026c instr jal a0,80000476 is causing pc to jump to a misaligned address. If misaligned access is enabled and DUT/Sail has compressed instruction support, then DUT/Sail will execute c.nop instruction and no exception will be thrown, but in your case, when misaligned-access is disabled and/or compressed instruction support does not exist, then it will cause misaligned-fetch exception and will call the trap handler. You will see the following prompt in Sail log file in your case, mem[X,0x8000026C] -> 0x056F mem[X,0x8000026E] -> 0x20A0 [107] [M]: 0x8000026C (0x20A0056F) jal a0, 522 trapping from M to M to handle misaligned-fetch handling exc#0x00 at priv M with tval 0x80000476 CSR mstatus <- 0x00001800 For reference => Line 645-650 (in the given log file) Here mtval is getting 0x80000476 value showing you the misaligned address. This address is same as where you have seen .short 0x0000 or .2byte 0x0 (both are the same things). Upon returning from the trap (or no trap in case-1), the program will keep executing instructions line by line. ------------------------------ Now, the address 0x80000476 is also in code region, so DUT/Sail will eventually reach to this address to execute this instruction. Over here, it will fetch a compressed instruction, if compressed instruction is supported by DUT/Sail, it will execute that c.nop instruction, otherwise (when compressed support is not there => Your case) it will cause illegal-instruction exception and once again calls the trap handler. For your case, you will see the following prompt in Sail log. mem[X,0x80000474] -> 0x0000 [453] [M]: 0x80000474 (0x0000) c.illegal 0 trapping from M to M to handle illegal-instruction handling exc#0x02 at priv M with tval 0x00000000 CSR mstatus <- 0x00001800 For reference => Line 2636-2641 in the given log file In either case (trap or no trap), the program will complete its execution without any trouble, so you should be getting an exit from this program and this test will be passing on both DUT and Sail in all possible cases (with/without misaligned, with/without compressed support), so dont worry if you are seeing any compressed instruction in your disass, it is there for deliberate reason. — Reply to this email directly, view it on GitHub <#442 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJQYPOUPVHKSUSK3DNTYYKAWNAVCNFSM6AAAAABERBGLECVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJYHE2TQNJTGI> . You are receiving this because you commented.Message ID: ***@***.***>

Answer 6 · 2024-03-16T14:40:07.000Z

@UmerShahidengr
My understanding was that the testcase has one objective to test the misaligned fetch implementation on RV32I cores, now I understand that a core that implements misaligned fetch exception but it does not implement illegal instruction exception should fail this test. Thank you for the detailed explanation! Now it is clear on the generated compressed instructions.

Answer 7 · 2024-03-16T14:44:03.000Z

@allenjbaum
Signatures were different from DUT and Sail. Will close this as resolved because test is deliberately inserting c.nop! Thank you for your help!