forked from riscv-software-src/riscv-tests
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merge upstream repository into noop #5
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…rc#485) * Add an exclude list for known failing Hifive1 tests This commit adds a list of known failing tests based on: riscv-collab/riscv-openocd#869 (comment) * Fix name of the HiFive1 flash target Signed-off-by: Marek Vrbka <[email protected]> --------- Signed-off-by: Marek Vrbka <[email protected]>
flushregs is deprecated.
…shregs debug: flushregs -> maintenance flush register-cache
Just so it's easier to quickly comment out code and hard-code the target to use without pylint complaining. This really should be a command line option.
It's a bit messy to read the log file to get the output, but it seems to be flushed often so that this works. Also, added the `targets` method for retrieving the list of targets, and `wait_until_running` method to wait until all targets are in a running state.
Use the new spike mechanism to test OpenOCD behavior when a hart becomes unavailable while running. Create CommandException.
Use new spike mechanism to test OpenOCD behavior when the current hart becomes unavailable while running. Create ThreadTerminated exception.
Use new spike mechanism to test OpenOCD behavior when a hart becomes unavailable, and then available again.
…er_dance debug: Test OpenOCD behavior when harts become unavailable, using new spike mechanism
They have issues when run in a github workflow.
…able_unavailable debug: Disable unavailable tests.
Just doing this to make a change in the debug files, which should now cause the pylint workflow to execute.
…int_workflow debug: Only run pylint if debug files changed.
This should avoid problems like we just had where bad tests can break the OpenOCD workflow. These tests only run if any debug files are changed, so should have no impact at all on non-debug tests in this repo. This file is copied and then slightly changed from riscv-openocd. New changes are that cacheable steps (building spike, OpenOCD) are stored to the cache even if running the tests fails.
…ug_workflow debug: Actually run tests in github workflow.
During the github workflow this character is \n, while on my computer it's ' '. I'm sure there's a good reason for that, but it doesn't seem worth figuring out what that reason is.
…vailable debug: Re-enable unavailable tests, and fix them for github
This lets you reproduce a test running on a specific hart.
Actually wait for the command to be echoed back. This means we won't be confused if there are extra newlines in gdb output.
…ug_hart debug: Add --hart command line option to gdbserver.py
…errupt_all debug: Fix interrupt_all() to restore state.
…gets debug: Make Openocd.targets() tolerate blank lines.
…peat-read Remove old warning check in RepeatReadTest
…ed data present in pexpect match Problem was observed on UnavailableMultiTest - this test was sporadically failing. When the failure was observed the log of the failing test looked as follows: ``` File "/whatever/RISCVTests/debug/testlib.py", line 504, in <genexpr> if all(targets[hart.id]["State"] == "running" for hart in harts): ~~~~~~~~~~~~~~~~^^^^^^^^^ KeyError: 'State' ``` Adding this modification to testlib.py ``` --- a/debug/testlib.py +++ b/debug/testlib.py @@ -498,6 +498,10 @@ class Openocd: for line in lines[2:]: if line.strip(): data.append(dict(zip(headers, line.split()[1:]))) + str_data = str(data) + sys.stdout.flush() + sys.stdout.write(f"parsed targets:\n{result}\n===\n{str_data}\n---\n") + sys.stdout.flush() return data ``` Allowed me to root cause the issue. Namely we have the following situation: ``` parsed targets: Exception ignored in: <function _TemporaryFileCloser.__del__ at 0x7f2dee64d1c0> Traceback (most recent call last): File "/usr/local/lib/python3.11/tempfile.py", line 450, in __del__ self.close() File "/usr/local/lib/python3.11/tempfile.py", line 446, in close unlink(self.name) FileNotFoundError: [Errno 2] No such file or directory: '/tmp/[email protected]' ... TargetName Type Endian TapName State -- ------------------ ---------- ------ ------------------ ------------ 0 riscv.cpu0 riscv little riscv.cpu running 1* riscv.cpu1 riscv little riscv.cpu running === [{'Exception': '"/usr/local/lib/python3.11/tempfile.py",', 'ignored': 'line', 'in:': '450,', ... ``` The only reasonable (to me) explanation for the observed behavior is below. Here is how we connect to TCL-RPC server: ``` self.openocd_cli = pexpect.spawn(f"nc localhost {self.tclrpc_port}") tty.setraw(self.openocd_cli.child_fd) ``` Later we request target list by issuing "targets" command: ``` self.command("targets") ``` Internally, pexpect.spawn implemented as follows: - we fork the process - set up pty and then call execve - all these steps are written in python "Exception ignored" messages are result of exceptions thrown from finalizers of NamedTemporaryFile objects. When exception is thrown from the finalizer - python unconditionally prints a "warning" to stderr. It seems that these messages are polluting our output from "nc" since python GC can be invoked before the execve syscall. The workaround is just to make sure that execve was executed before we rely on the format of command output. To have such a guarantee we just issue a dummy "echo" command and check that we have a proper reply in the output stream. While this explanation looks convincing, the behavior above still looks strange, given that we have https://bugs.python.org/issue14548 which was resolved long ago. However, the proposed workaround fixes the issue.
Memory sampling tests fail sporadically for spike targets. A typical failure looks as follows (ROI from test log): ``` ---------------------------------[ Message ]---------------------------------- 139670831 not less than 124104544 --------------------------------[ Traceback ]--------------------------------- ... SECTION IS SKIPPED FOR READABILITY ... raise TestFailed(f"{a!r} not less than {b!r}", comment) testlib.TestFailed ``` Few observations: - 139670831 is 0x0853352f in hex, while 124104544 is 0x0765af60 - Now, the assert which is failing corresponds to the following expression: ``` assertLess(value, previous_value + tolerance) ``` - tolerance is `0x500000`. (124104544 - 0x500000) is 0x0715af60 If we look at the sampling output for such failing test, we'll see: ``` ... 0x1212340c5c: 0x0715af60 timestamp after: 878087500 timestamp before: 878088133 0x1212340c5c: 0x0853352f ... ``` The log above demonstrates the reason for the failure. Since memory sampling occures every poll (which by default happens approximately every 100ms) a value of the counter may exceed the threshold if the time between subsequent polls is increased (for whatever reason). In my opinion the failing assert can be safely removed, since the checks it perform are quite brittle and cannot be generalized. The assert violation is affected by CPU performance and sporadic delays between polls. For now, instead of assert removal we just avoid checks in-between memory sample bursts. This way we still can be certain that memory samples are frequent enough and hopefully this will avoid sporadic failures.
…_sporadic_failure debug: fix sporadic failures of memory sampling tests
…_faulure_fix debug: workaround for sporadic failures of some tests due to unexpected data present in pexpect match
HwbpManual test was broken: * Value read back from `tselect` was compared with `tdata1` value. https://github.com/riscv-software-src/riscv-tests/blob/408e461da11e0b298c4b69e587729532787212f5/debug/gdbserver.py#L701-L703 This resulted in the test being reported as not supported, after all the triggers were checked. * `tdata1.type` field was not set to `mcontrol`. * `tselect` value used to be changed by `handle_reset` and not restored. https://github.com/riscv-software-src/riscv-tests/blob/408e461da11e0b298c4b69e587729532787212f5/debug/programs/entry.S#L79-L84 * Manual breakpoint used to be left behind. Signed-off-by: Evgeniy Naydanov <[email protected]>
By using Zca-friendly registers, we can reuse the existing tests to get quick-and-dirty coverage of Zca, when the assembler is told to use Zca. (This doesn't break non-Zca targets.)
Continuation of fee361f
debug: fix HwbpManual test
…ib.py:run_all_tests()
…list-tests Debug: suppress `PRNG seed ...` log messages when `gdbserver.py --list-tests <target>` used
Signed-off-by: Daniel Maslowski <[email protected]>
merge .bss.* to .bss then entry.S can clear it.
The file was added by 00ab5f0 in riscv-software-src#567. Seems like a mistake. ``` > readelf -h debug/test ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: RISC-V Version: 0x1 Entry point address: 0x1212340000 Start of program headers: 64 (bytes into file) Start of section headers: 16552 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 2 Size of section headers: 64 (bytes) Number of section headers: 18 Section header string table index: 17 ```
After riscv-collab/riscv-openocd#1111 is merged, the registers a user wishes to have direct control of should be reserved. This is the case in `HwbpManual`. The test still works with older OpenOCD versions, since no exception is generated when a command (`riscv reserve_trigger` in this case) is not found.
riscv-software-src#578) issue#577 In the newest riscv spec(2021 or later), two csr register "sptbr"(0x180) "s/mbadaddr"(0x243) were removed, and upgraded to "satp" "s/mtval". Together with more functions. This commit rename them to pass compile.
…#579) There is already a mechanism for the test target to supply a known-bad address, so use that address if it is provided.
…igger [debug] Reserve the trigger in `HwbpManual`
Syntax of the command was changed: (on/off) became compulsory.
…igger-fix [debug] Fix trigger reservation in HwbpManual
riscv-collab/riscv-openocd#1111 introduces a change in OpenOCD behavior: a manual trigger should be manually removed to step/resume from it. This was not concidered in previous stop-gap solutions (76ff703 and 8cc4918) This commit: 1. Determines if `reserve trigger` is supported by the target. This can be removed once riscv-collab/riscv-openocd#1111 is merged. 2. Marks `HwbpManual` test as not applicable in case `reserve trigger` is not supported. 3. Accounts for the change in OpenOCD's behavior when stepping from a manual BP. 4. Cleans up some minor mistakes in `HwbpManual`
…igger-fix-propper [debug] Reserve triggers propperly in HwbpManual
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.