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>
Delete the old branch and pull a new one, because of a wrong force push. Git is not as easy as I think.
Signed-off-by: gr816ox <50945677+gr816ox@users.noreply.github.com>
the default target endian is always little endian:
- mmu::is_target_big_endian() return false
- sim_t::get_target_endianness() return memif_endianness_little
when RISCV_ENABLE_DUAL_ENDIAN macro is undefined
This replaces multiple uses of `std::vector::operator[]` where the
parameter is a constant `0` with the use of C++11's `std::vector::data`
method. This fixes the root cause of invalid memory accesses.
`std::vector::operator[]` is an unchecked memory access, and when the
buffers are zero-sized (that is the buffer container is empty) either
due to a 0 padding in the case of elfloader or NULL parameters to
syscalls where permitted, the unchecked access may cause an invalid
memory access. The use of `std::vector::data` is permitted even in such
a case, though the returned memory may not be dereferenced. The general
usage of the returned pointer is to pass to `memif_t`, which is careful
about 0-sized buffer accesses, and so passing the result of
`std::vector::data` is safe. This is theoretically a better access
pattern as it also avoids having the compiler to re-materialize the
pointer from the de-referenced location.
`std::vector::operator[]` does not perform a bounds check when accessing
the underlying memory. If the length of the padding is 0, this would
access an invalid memory location. Guard against this by ensuring that
we have any padding to apply by constant hoisting the length computation
and checking the value.
Precompiled headers were broken because they weren't compiled with
the same -fPIC setting as the rest of the code. Fix by just making
everything use -fPIC.
* reduce sig_len constraint to 4 bytes
Spike currently asserts that the signature length should always be a multiple of 16-bytes. However, the compliance suite has agreed to upon the signature being a multiple ot 4-bytes. This prevents some of the tests to run on spike since it fails the assertion.
The proposed change fixes this issue and reduces the assertion to 4 bytes.
* Added size argument to htif arguments and zero padding for signature output. Defaultline size-16.
* Modified type of line_size to unsigned.
* Renamed size to granularity.
* Rename granularity to signature-granularity.
Co-authored-by: dracarys99 <spawan1999@gmail.com>
Julien Olivain
Jerry Zhao
Sagar Karandikar
Viktor Prutyanov
gr816ox
Andrew Waterman
Jerin Joy
Iman Hosseini
Weiwei Li
John Fang
Saleem Abdulrasool
Chih-Min Chao
huaixv
Daniel Bates
Marcus Comstedt
S.Pawan Kumar
Neel Gala