Re: [PATCH 2/4] Fall back to a default value of 0 for the MISA register.

[Jim Wilson <jimw@sifive.com>]

On Wed, Sep 19, 2018 at 4:20 PM John Baldwin <jhb@freebsd.org> wrote:
> MISA is a machine-mode register in RISC-V which may or may not be
> available to supervisor operating systems.  Rather than requiring
> targets to always provide a fake MISA value, fallback to 0 for now.
> (The Linux native target currently always provides a fake value of 0
> for MISA.)

The linux target provides a fake value for misa because gdb is a side
project for me, and I haven't had time to add ptrace support for it
yet.  Too many binutils and gcc problems I need to fix first.

I think providing a default misa value in riscv-tdep.c is a mistake.
One major problem is with the use of compressed breakpoints.  Consider
the case where the target has compressed instruction support, the C
library was compiled to use compressed instructions, and the user
program was compiled without compressed instruction support.  If we
can't read misa, then we check the program ELF headers, see that there
is no compressed instruction support, and start using 4-byte
breakpoints.  Storing a 4 byte breakpoint into a library compiled with
compressed instructions means that we will be clobbering instructions
and things start breaking badly.  I ran into this earlier before
fixing some bugs in the breakpoint support in riscv-tdep.c.  Glibc
provides a stub function for gdb support that happens to be exactly 2
bytes long.  Storing a 4-byte breakpoint there clobbers the first
instruction of the next function, which happens to be an important
function for program startup, which means we get an illegal
instruction error before even reaching main which is very confusing.

If we can read misa, then we don't have this problem, as we will
always know if the hardware supports compressed breakpoints, and we
can avoid this problem.  If we can't read misa, then we will have to
check the ELF headers of every shared library used by a program,
including the interpreter ld.so, to see if any of them use compressed
instructions.  We will also have to check every library loaded at
run-time via dlload.  This seems like a hassle.  Another option might
be to try to execute a 2-byte breakpoint to see if it works or not,
and then use compressed breakpoints if they work, but this also seems
like a hassle.  Reading misa seems like the easy solution, all I need
is a linux kernel patch to add ptrace support for reading it.  If we
have access to misa, then we also know whether FP registers are
present, and their size, which is also important info that we can't
easily get any other way.  misa is roughly equivalent to x86 cpuid.  I
don't know of any reason why misa wouldn't be available to the OS.

I suppose another option here might be the auxvec/hwcap info.  Maybe
info about compressed instructions and FP support can be passed from
the kernel to the user program this way, and then maybe gdb can get
the info from there, if gdb has some way to read and parse
auxvec/hwcap info passed to the user program.

Jim