Format 1/2 updiscon not set in referenceFlow
eflaner opened this issue · 1 comments
eflaner commented
The spec in 7.6.2 specifies four scenarios in which, the second one says: (trimmed for ease )
..... jumps back to looplabel, but there is then an exception .....
In this case, the encoder reports looplabel using format 1/2 following the JALR, with updiscon == !notify, and the next packet is a format 3
To avoid length - dropdown is used, please click to expand
I've a MWE, which tries to Jump and creates an exception,
_start:
li t0, 1
slli t0, t0, 31
bltz t0, 1f
2:
j 2b
1:
la t0, trap_entry
csrw mtvec, t0
la t0, this_point
jr t0
.align 2
trap_entry:
csrr a0, mcause
j _end
this_point:
unimp
_end:
la t1, tohost
li t2, 1
sw t2, 0(t1)
j 2b
Post linker file the disassembly looks like
80000000 <_start>:
80000000: 00100293 li t0,1
80000004: 01f29293 slli t0,t0,0x1f
80000008: 0002c463 bltz t0,80000010
8000000c: 0000006f j 8000000c
80000010: 00000297 auipc t0,0x0
80000014: 01828293 addi t0,t0,24 # 80000028 <trap_entry>
80000018: 30529073 csrw mtvec,t0
8000001c: 00000297 auipc t0,0x0
80000020: 01428293 addi t0,t0,20 # 80000030 <this_point>
80000024: 00028067 jr t0
80000028 <trap_entry>:
80000028: 34202573 csrr a0,mcause
8000002c: 0080006f j 80000034 <_end>
80000030 <this_point>:
80000030: c0001073 unimp
80000034 <_end>:
80000034: 00001317 auipc t1,0x1
80000038: fcc30313 addi t1,t1,-52 # 80001000 <tohost>
8000003c: 00100393 li t2,1
80000040: 00732023 sw t2,0(t1)
80000044: fc9ff06f j 8000000c
On running the above elf in reference flow (in default -- itype3_basic)
the crt.encoder_input (trimmed until _start ) is attached_below
| itype_0 | cause | tval | priv | iaddr_0 | context | ctype | iretire_0 | ilastsize_0 |
|---|---|---|---|---|---|---|---|---|
| 0 | 0 | 0 | 3 | 80000000 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000004 | 0 | 0 | 1 | 1 |
| 5 | 0 | 0 | 3 | 80000008 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000010 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000014 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000018 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 8000001c | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000020 | 0 | 0 | 1 | 1 |
| 6 | 0 | 0 | 3 | 80000024 | 0 | 0 | 1 | 1 |
| 1 | 2 | 73 | 3 | 80000030 | 0 | 0 | 0 | 1 |
| 0 | 0 | 0 | 3 | 80000028 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 8000002c | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000034 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000038 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 8000003c | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000040 | 0 | 0 | 1 | 1 |
| 0 | 0 | 0 | 3 | 80000044 | 0 | 0 | 1 | 1 |
te_inst is generated as
| format | subformat | address | branch | branches | branch_map | branch_count | branch_fmt | context | ecause | ienable | encoder_mode | interrupt | irreport | irdepth | notify | ioptions | privilege | qual_status | time | thaddr | tval | updiscon |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 3 | 3 | _ | _ | _ | _ | _ | _ | _ | _ | 1 | 0 | _ | _ | _ | _ | 0 | _ | 0 | _ | _ | _ | _ |
| 3 | 0 | 800 | 1 | _ | _ | _ | _ | 0 | _ | _ | _ | _ | _ | _ | _ | _ | 3 | _ | _ | _ | _ | _ |
| 2 | _ | 3ffff800 | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | 0 | _ | 0 | _ | _ | _ | _ | _ | _ | 0 |
| 1 | _ | 12 | _ | 1 | 0 | _ | _ | _ | _ | _ | _ | _ | 0 | _ | 0 | _ | _ | _ | _ | _ | _ | 0 |
| 3 | 1 | 40000018 | 1 | _ | _ | _ | _ | 0 | 2 | _ | _ | 0 | _ | _ | _ | _ | 3 | _ | _ | 0 | 73 | _ |
| 3 | 0 | 40000014 | 1 | _ | _ | _ | _ | 0 | _ | _ | _ | _ | _ | _ | _ | _ | 3 | _ | _ | _ | _ | _ |
| 2 | _ | e | _ | _ | _ | _ | _ | _ | _ | _ | _ | _ | 0 | _ | 0 | _ | _ | _ | _ | _ | _ | 0 |
| 3 | 3 | _ | _ | _ | _ | _ | _ | _ | _ | 0 | 0 | _ | _ | _ | _ | 0 | _ | 1 | _ | _ | _ |
In the above the format 1 te_inst is released before the exception according to the specification, updiscon should be 1 instead of 0 ( or did i interpret the specification wrongly ? )
The contents of crt.decoder.trace is below in which the "exception" causing addr is missing.
80000000
80000004
80000008
80000010
80000014
80000018
8000001c
80000020
80000024
80000028
8000002c
80000034
80000038
8000003c
80000040
80000044
The decoded trace also misses the presence of 80000030 -- is this referenceFlow problem ?
IainCRobertson commented
Babu,
This all looks correct to me. See my comments in line
Iain
From: Babu P S ***@***.***>
Sent: 31 March 2023 20:14
To: riscv-non-isa/riscv-trace-spec ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [riscv-non-isa/riscv-trace-spec] Format 1/2 updiscon not set in referenceFlow (Issue #82)
The spec in 7.6.2 specifies four scenarios in which, the second one says: (trimmed for ease )
..... jumps back to looplabel, but there is then an exception .....
In this case, the encoder reports looplabel using format 1/2 following the JALR, with updiscon == !notify, and the next packet is a format 3
To avoid length - dropdown is used, please click to expand
I've a MWE, which tries to Jump and creates an exception,
_start:
li t0, 1
slli t0, t0, 31
bltz t0, 1f
2:
j 2b
1:
la t0, trap_entry
csrw mtvec, t0
la t0, this_point
jr t0
.align 2
trap_entry:
csrr a0, mcause
j _end
this_point:
unimp
_end:
la t1, tohost
li t2, 1
sw t2, 0(t1)
j 2b
Post linker file the disassembly looks like
80000000 <_start>:
80000000: 00100293 li t0,1
80000004: 01f29293 slli t0,t0,0x1f
80000008: 0002c463 bltz t0,80000010
8000000c: 0000006f j 8000000c
80000010: 00000297 auipc t0,0x0
80000014: 01828293 addi t0,t0,24 # 80000028 <trap_entry>
80000018: 30529073 csrw mtvec,t0
8000001c: 00000297 auipc t0,0x0
80000020: 01428293 addi t0,t0,20 # 80000030 <this_point>
80000024: 00028067 jr t0
80000028 <trap_entry>:
80000028: 34202573 csrr a0,mcause
8000002c: 0080006f j 80000034 <_end>
80000030 <this_point>:
80000030: c0001073 unimp
80000034 <_end>:
80000034: 00001317 auipc t1,0x1
80000038: fcc30313 addi t1,t1,-52 # 80001000 <tohost>
8000003c: 00100393 li t2,1
80000040: 00732023 sw t2,0(t1)
80000044: fc9ff06f j 8000000c
On running the above elf in reference flow (in default -- itype3_basic)
the crt.encoder_input (trimmed until _start ) is attached_below
itype_0
cause
tval
priv
iaddr_0
context
ctype
iretire_0
ilastsize_0
0
0
0
3
80000000
0
0
1
1
0
0
0
3
80000004
0
0
1
1
5
0
0
3
80000008
0
0
1
1
0
0
0
3
80000010
0
0
1
1
0
0
0
3
80000014
0
0
1
1
0
0
0
3
80000018
0
0
1
1
0
0
0
3
8000001c
0
0
1
1
0
0
0
3
80000020
0
0
1
1
6
0
0
3
80000024
0
0
1
1
1
2
73
3
80000030
0
0
0
1
0
0
0
3
80000028
0
0
1
1
0
0
0
3
8000002c
0
0
1
1
0
0
0
3
80000034
0
0
1
1
0
0
0
3
80000038
0
0
1
1
0
0
0
3
8000003c
0
0
1
1
0
0
0
3
80000040
0
0
1
1
0
0
0
3
80000044
0
0
1
1
te_inst is generated as
format
subformat
address
branch
branches
branch_map
branch_count
branch_fmt
context
ecause
ienable
encoder_mode
interrupt
irreport
irdepth
notify
ioptions
privilege
qual_status
time
thaddr
tval
updiscon
3
3
_
_
_
_
_
_
_
_
1
0
_
_
_
_
0
_
0
_
_
_
_
3
0
800
1
_
_
_
_
0
_
_
_
_
_
_
_
_
3
_
_
_
_
_
2
_
3ffff800
_
_
_
_
_
_
_
_
_
_
0
_
0
_
_
_
_
_
_
0
1
_
12
_
1
0
_
_
_
_
_
_
_
0
_
0
_
_
_
_
_
_
0
3
1
40000018
1
_
_
_
_
0
2
_
_
0
_
_
_
_
3
_
_
0
73
_
3
0
40000014
1
_
_
_
_
0
_
_
_
_
_
_
_
_
3
_
_
_
_
_
2
_
e
_
_
_
_
_
_
_
_
_
_
0
_
0
_
_
_
_
_
_
0
3
3
_
_
_
_
_
_
_
_
0
0
_
_
_
_
0
_
1
_
_
_
In the above the format 1 te_inst is released before the exception according to the specification, updiscon should be 1 instead of 0 ( or did i interpret the specification wrongly ? )
[Iain] Your interpretation is wrong. The format 1 reports the final retired instruction before the exception (the jr at address 0x80000024). The updiscon bit is set if the packet is reporting the instruction following an uninferable discontinuity. The previous instruction was addi, which does not cause an updiscon. As such it is correct that the updiscon bit is not set (i.e. has the same value as notify).
The contents of crt.decoder.trace is below in which the "exception" causing addr is missing.
80000000
80000004
80000008
80000010
80000014
80000018
8000001c
80000020
80000024
80000028
8000002c
80000034
80000038
8000003c
80000040
80000044
The decoded trace also misses the presence of 80000030 -- is this referenceFlow problem ?
[Iain] No. The decoded trace lists the instructions which retired. The instruction which caused the exception (0x80000030) did not retire, and so is not reported as part of the trace. In the decoder pseudo code in the spec, there is a stub function report_epc which can be used to report details of the exception address, but the content of this function is left as an implementation detail, and is not implemented in the reference flow.
-
Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Friscv-non-isa%2Friscv-trace-spec%2Fissues%2F82&data=05%7C01%7Ciain.robertson%40siemens.com%7C819610b88a2f4578717708db321c2045%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638158868597500433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=r2J%2FqDo9jkdJqgF4mU1FB5eD%2FQ0ZdQju0JS6XmRsXrw%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALQOPSRC3V7SRNGLD6FWFKLW64UITANCNFSM6AAAAAAWPA7VRY&data=05%7C01%7Ciain.robertson%40siemens.com%7C819610b88a2f4578717708db321c2045%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638158868597500433%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yHBHITuQzOjObjnGo2K89Ad7nc0axLlEuFKdI8p%2FQic%3D&reserved=0>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.******@***.***>>