Fix inconsistent behavior between NEMU and XiangShan in rdtime inst, fix some type errors

[BL-GS]

1. When generating and executing checkpoints according to the tutorials or README.md, it may incur confusing errors. I found that NEMU only restores a part of gcpt.bin.

restore.sh uses different shell commands from those in tutorials and thus bypasses this question.

2. The directory name becomes negative number when inst_count exceeds the limitation of int. I fixed it.
3. Because XiangShan hasn't implemented user-level timer and requires emulation of firmware, like opensbi, which acquires illegal instruction exception to judge whether the CPU supports RDTIME instruction(https://github.com/riscv-software-src/opensbi/blob/master/lib/sbi/sbi_hart.c):

       /* Detect if hart supports time CSR */
       csr_read_allowed(CSR_TIME, (unsigned long)&trap);
       if (!trap.cause)
   	    __sbi_hart_update_extension(hfeatures,
   				    SBI_HART_EXT_ZICNTR, true);

   By the way, it is also called SBI_HART_EXT_TIME before the commit in July.

[xyyy1420]

1. That's my fault, thanks for fixing. By the way, restore.sh using --cpt-restore solves(with some limitations) the problem caused by the difference between the older gcpt.bin and the new gcpt.bin, rather than bypass it.
2. I think it needs to be fixed.

[BL-GS]

As for the third change, my prior explanation might be a little confusing. Let me give an example(without the change):

1. At first, we generate checkpoints by NEMU, which emulates user-level timer(0xc01) successfully and sets SBI_HART_EXT_ZICNTR bit in the variable hfeature.

  /* Detect if hart supports time CSR */
  csr_read_allowed(CSR_TIME, (unsigned long)&trap);
  if (!trap.cause)
	  __sbi_hart_update_extension(hfeatures,
				  SBI_HART_EXT_ZICNTR, true);

2. We run checkpoint on Xiangshan, and it restores the variable hfeature in memory.
3. When application executes instruction rdtime and tries to read user-level timer(0xc01), it raises illegal instruction exception(because XiangShan doesn't support it), enters M-mode and awakes OpenSBI to handle the exception(opensbi/lib/sbi/sbi_illegal_insn.c).
4. OpenSBI tries to emulate the behavior. However, this is what it does:

// opensbi/lib/sbi/sbi_timer.c
if (sbi_hart_has_extension(scratch, SBI_HART_EXT_ZICNTR))
	get_time_val = get_ticks;

where the function get_ticks is:

// opensbi/lib/sbi/sbi_timer.c
#if __riscv_xlen == 32
static u64 get_ticks(void)
{
	u32 lo, hi, tmp;
	__asm__ __volatile__("1:\n"
			     "rdtimeh %0\n"
			     "rdtime %1\n"
			     "rdtimeh %2\n"
			     "bne %0, %2, 1b"
			     : "=&r"(hi), "=&r"(lo), "=&r"(tmp));
	return ((u64)hi << 32) | lo;
}
#else
static u64 get_ticks(void)
{
	unsigned long n;

	__asm__ __volatile__("rdtime %0" : "=r"(n));
	return n;
}
#endif

Yeah, it executes the instruction rdtime again in M-mode. It will raise illegal instruction exception, but OpenSBI does not allow illegal instruction exception in M-mode(Even if it did, the program would be stuck in an infinite loop):

// opensbi/lib/sbi/sbi_illegal_insn.c
if (prev_mode == PRV_M) {
	sbi_printf("%s: Failed to access CSR %#x from M-mode",
		__func__, csr_num);
	return SBI_EFAIL;
}

[xyyy1420]

seems ok