It caused compile error "use of undeclared identifier 'errno'" at line 26 and 33.
I Add #include <cerrno> in fesvr/elfloader.cc to fix error and compile successfully.
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.
Stricter validation of ELF binaries improves usability with informative
assertions. This prevents users from loading ELF relocatable files and
binaries compiled for their (non-RISC-V) workstations, for example.
Without this patch, spike would attempt to load nearly any ELF given,
but it would usually fail with an error about debug module accesses,
since the given ELF causes accesses in the debug module's memory space.
Even if spike successfully loaded the ELF file, it would still misbehave
during simulation, for example in the case of ELF relocatable files.
ELF magic numbers come from official ELF documents:
TIS ELF spec v1.2, via Linux Foundation Referenced Specifications
See: https://refspecs.linuxbase.org/
RISC-V magic number comes from official RISC-V ELF documents:
See: riscv/riscv-elf-psabi-doc@60c25981b62c0b43d16142f8a12c8b1e98e60d4d