| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Asserts (especially without a message) aren't human readable way of
error reporting. So, replace them by exceptions with messages with
errno string.
|
|
chaining
This step is to ensure that removing config.h out of headers will not cause regressions.
|
|
|
|
Set target endianess in constructors
|
|
code and emits an error message to help avoid unintentionally loading wrong elf.
|
|
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.
|
|
This simply uses clang-format to reflow the text of the macro, which
makes it easier to read and edit.
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
