fesvr: fix compilation with gcc 13

Fix the relationship between Zce and Zcf

Compiling spike with gcc 13 (for example, included in Fedora 38
prerelease) fails with error:

    In file included from fesvr/syscall.h:6,
                     from fesvr/syscall.cc:4:
    fesvr/device.h:15:30: error: ‘uint64_t’ was not declared in this scope
       15 |   typedef std::function<void(uint64_t)> callback_t;
          |                              ^~~~~~~~

This is due to a gcc header dependency change. See for reference:
https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes



This commit explicitly adds the missing <cstdint> header inclusion
to fix this build failure.

Signed-off-by: Julien Olivain <ju.o@free.fr>

Use simif_t for devices

In keeping with the spirit of simif_t.

In keeping with the spirit of simif_t.

So we can soon convert those classes to use simif_t instead of sim_t.

To be explicit about which methods of simif_t and htif_t we implement.

Add +symbol_elf flag to fesvr to support loading in symbols from other elf files

When populated, symbol_elfs are additional elf files that populate the
addr2symbol map in htif

Fix ctrl-c responsiveness when running in interactive mode

Break out of the interactive_run->interactive_run loop when ctrlc_pressed

Signed-off-by: Jerry Zhao <jerryz123@berkeley.edu>

Support passing in htif target-arguments through plusargs

make target_args() protected instead of private to allow subclasses to inject args

Don't issue misaligned or non-power-of-2 MMIO accesses

@aswaterman explains:

Rather than requiring each MMIO device to support arbitrary sizes and
alignments, decompose MMIO misaligned loads and stores in such a way
as to guarantee their constituent parts are always aligned.
(Specifically, they now always decompose to a sequence of one-byte
accesses.)

This is not a semantic change for main-memory accesses, but it is a
semantic change for I/O devices.  It makes them more realistic, in that
most bus standards don't support non-power-of-2-sized accesses.

Misaligned MMIO is unspecified but this is simple enough.

update support for Zc* to v1.0.3

Initialize MTIP at reset

Define sim_t::INTERLEAVE so that it can be accessed by reference

Since mtime and mtimecmp both initialize to 0, and "a machine timer
interrupt becomes pending whenever mtime contains a value greater than
or equal to mtimecmp," MTIP should be 1.

Before this change, MTIP would be 0 until the first increment, or
until reading/writing from CLINT regs (since clint_t::load() and
clint_t::store() call increment(0)).

PLIC and CLINT fixes for heterogeneous harts/discontiguous hart IDs

std::min takes its arguments by reference, so the arguments need to be
defined.  An alternative would have been to force the problematic argument
into being an rvalue (e.g., by adding 0), but this approach seems to me
to be more robust.

This fixes compilation under -O0; see https://github.com/riscv-software-src/riscv-isa-sim/pull/1264#issuecomment-1451114717

@scottj97 I posit that this situation is unusual enough that it shouldn't
motivate us to test -O0 in CI.

This is a large delta because the old implementation baked in multiple
assumptions about the contiguity of hart IDs.

As a side effect, fix implementation for big-endian hosts.

It's safe to overwrite bytes when returning false.

This commit started as an attempt to make the PLIC tolerant of
discontiguous hart IDs, but it turns out it was already most of
the way there: PLIC contexts can still be dense even if the hart
IDs are not.

Nevertheless, I wanted to avoid passing the procs vector directly to
the plic_t constructor.  In removing it, I realized I could also get
rid of the smode parameter by querying whether each hart has S-mode.
This is also more correct; previously, we were instantiating the PLIC
as though all harts had S-mode, regardless of whether they actually did.