| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This includes detection for:
- Stack underflows (it was theoretically already there but it had never
been properly tested).
- Load/store out of bounds for a given variable known via the .nasm/
directory.
- Load out of bounds on a set of data referenced via a raw label (see
commit aa5174fc055d ("xixanta: Add an hint for the ending of data
labels")).
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
|
|
|
| |
Make the hexadecimal values more cohesive and avoid having a
variable-sized line because of them.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
|
|
|
|
| |
When reporting the final instruction, if that was actually a brk (and
hence we stopped because of it), show the breaking mark as that could be
relevant when debugging.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
| |
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
|
|
| |
Add also a test to further check corner cases on compare instructions.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This also includes brk and rti, for which we are also storing and
exporting the break mark, just in case it can be useful to library users
in case they want to add error codes in break marks.
This commit also includes a fix for accounting the Z and N flags on
transfer instructions, which couldn't easily be split into a separate
commit, but it's a fairly simple change.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
|
|
|
|
| |
On situations like jsr or rts, we perform two pushes/pops, but this is
not to be reported in verbose mode as it's not that clear. Instead,
let's report the full address in a single stack line.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
| |
|
|
| |
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|
|
|
The vnf library supports the runrom crate and they both combined enable
users to "run" a ROM file. This is basically an emulator, but with two
key differences:
1. It is to be run programatically. That is, you are not expected to
play games with this, but to run code by steps, start at a given
address, run a function, etc.
2. It is headless: there are no graphics displayed on screen, nor sound
being delivered.
Thus, the target for both these things are developers, not players. This
way developers can validate code paths without needing a full blown
emulator. You can write tests with this and be able to run some checks
as part of your testing infrastructure.
Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
|