The riscv64 Hifive Unmatched is the only platform that
failed on testcase TestAnalyzeAnnotations occasionally
after CL 332954 had merged. The failure happens when
ticks per second (freq) is over 1e12 which causing the timestamps
of two events are same.
There are 2 reasons causing big frequency:
1. RDCYCLE is HART based according to the riscv manual which makes
negative ticks delta
2. negative float64 -> uint64 is undefined and "lucky" negative float
is too big to handle for trace
For #46737
Change-Id: I1f3c1ac31aae249969000c719c32aaf5a66d29a5
Reviewed-on: https://go-review.googlesource.com/c/go/+/373034
Trust: Zhuo Meng <mzh@golangcn.org>
Run-TryBot: Zhuo Meng <mzh@golangcn.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
// func cputicks() int64
TEXT runtime·cputicks(SB),NOSPLIT,$0-8
- RDCYCLE A0
+ // RDTIME to emulate cpu ticks
+ // RDCYCLE reads counter that is per HART(core) based
+ // according to the riscv manual, see issue 46737
+ RDTIME A0
MOV A0, ret+0(FP)
RET
trace.footerWritten = true
// Use float64 because (trace.ticksEnd - trace.ticksStart) * 1e9 can overflow int64.
freq := float64(trace.ticksEnd-trace.ticksStart) * 1e9 / float64(trace.timeEnd-trace.timeStart) / traceTickDiv
+ if freq <= 0 {
+ throw("trace: ReadTrace got invalid frequency")
+ }
trace.lockOwner = nil
unlock(&trace.lock)
var data []byte