As mentioned at User mode tests, tests under userland/libs require certain optional libraries to be installed, and are not built or tested by default.
+As mentioned at userland/libs directory, tests under userland/libs require certain optional libraries to be installed, and are not built or tested by default.
You can install those libraries with:
@@ -7389,7 +7393,7 @@ qw ertests that require user interaction
tests that take perceptible ammounts of time
+tests that take perceptible amounts of time
known bugs we didn’t have time to fix ;-)
@@ -7397,7 +7401,7 @@ qw erTests under userland/libs/ depend on certain libraries being available on the target, e.g. BLAS for userland/libs/openblas. They are not run by default, but can be enabled with --package and --package-all.
Tests under userland/libs/ are only run if --package or --package-all are given as described at userland/libs directory.
The gem5 tests require building statically with build id static, see also: Section 10.7, “gem5 syscall emulation mode”. TODO automate this better.
The build outputs are automatically stored in a different directories for optimized and debug builds, which prevents debug files from overwriting opt ones. Therefore, --gem5-build-id is not required.
The price to pay for debuggability is high however: a Linux kernel boot was about 3x slower in QEMU and 14 times slower in gem5 debug compared to opt, see benchmarks at: Section 29.2.1, “Benchmark Linux kernel boot”
+The price to pay for debuggability is high however: a Linux kernel boot was about 3x slower in QEMU and 14 times slower in gem5 debug compared to opt, see benchmarks at: Section 29.2.1, “Benchmark Linux kernel boot”.
+Similar slowdowns can be observed at: Section 29.2.2, “Benchmark emulators on userland executables”.
When in QEMU text mode, using --debug-vm makes Ctrl-C not get passed to the QEMU guest anymore: it is instead captured by GDB itself, so allow breaking. So e.g. you won’t be able to easily quit from a guest program like:
While GDB "has" this feature, it is just too broken to be usable, and so we expose the amazing Mozilla RR tool conveniently in this repo: https://stackoverflow.com/questions/1470434/how-does-reverse-debugging-work/53063242#53063242
Before the first usage:
+Before the first usage setup rr with:
This will first run the program once until completion, and then restart the program at the very first instruction at _start and leave you in a GDB shell.
This will:
+first run the program once until completion or crash
+then restart the program at the very first instruction at _start and leave you in a GDB shell
From there, run the program until your point of interest, e.g.:
@@ -16879,6 +16896,14 @@ continueThe use case of rr is often to go to the final crash and then walk back from there, so you often want to automate running until the end after record with --debug-vm-args as in:
./run --debug-vm-args='-ex continue' --debug-vm-rr --userland userland/c/hello.c+
Programs often tend to blow up in very low frames that use values passed in from higher frames. In those cases, remember that just like with forward debugging, you can’t just go:
Also mentioned at: https://stackoverflow.com/questions/47320800/how-to-clean-only-target-in-buildroot
See this for a sample manual workaround: Section 21.8.3.4, “PARSEC uninstall”.
+See this for a sample manual workaround: Section 21.8.4.4, “PARSEC uninstall”.
containers
+associative
+Algorithms contains a benchmark comparison of different c++ containers
+userland/cpp/set.cpp: std::set contains unique keys
We have ported parts of the PARSEC benchmark for cross compilation at: https://github.com/cirosantilli/parsec-benchmark See the documentation on that repo to find out which benchmarks have been ported. Some of the benchmarks were are segfaulting, they are documented in that repo.
./build --arch arm --download-dependencies gem5-buildroot parsec-benchmark @@ -24443,7 +24504,7 @@ times[3 * ntimes + k] = mysecond() - times[3 * ntimes + k];
Running a benchmark of a size different than test, e.g. simsmall, requires a rebuild with:
Most users won’t want to use this method because:
If you want to remove PARSEC later, Buildroot doesn’t provide an automated package removal mechanism as mentioned at: Section 20.6, “Remove Buildroot packages”, but the following procedure should be satisfactory:
If you end up going inside submodules/parsec-benchmark to hack up the benchmark (you will!), these tips will be helpful.
Tests under userland/libs require certain optional libraries to be installed on the target, and are not built or tested by default, you must enable them with either:
+--package <package> +--package-all+
See for example BLAS.
+Example: userland/arch/aarch64/ld2.S
userland/arch/aarch64/freestanding/linux/wfe.S
userland/arch/aarch64/freestanding/linux/wfe_wfe.S: run WFE twice, because gem5 390a74f59934b85d91489f8a563450d8321b602d does not sleep on the first, see also: gem5 ARM WFE
and power consumption is key in ARM applications.
SEV is not the only thing that can wake up a WFE, it is only an explicit software way to do it. Notably, global monitor operations on memory accesses of regions marked by LDAXR and STLXR instructions can also wake up a WFE sleeping core. This is done to allow spinlocks opens to automatically wake up WFE sleeping cores at free time without the need for a explicit SEV.
-Quotes for the above ARMv8 architecture reference manual db G1.18.1 "Wait For Event and Send Event":
For how userland spinlocks and mutexes are implemented see Userland mutex implementation.
Examples:
+SEV is not the only thing that can wake up a WFE, it is only an explicit software way to do it.
+Notably, global monitor operations on memory accesses of regions marked by LDAXR and STLXR instructions can also wake up a WFE sleeping core.
+This is done to allow spinlocks opens to automatically wake up WFE sleeping cores at free time without the need for a explicit SEV.
+In the shown in the wfe_ldxr_stxr.cpp example, which can only terminate in gem5 user mode simulation because due to this event.
Note that that program still terminates when running on top of the Linux kernel as explained at: WFE from userland.
+WFE and SEV are usable from userland, and are part of an efficient spinlock implementation (which userland should arguably stay away from and rather use the futex system call which allow for non busy sleep instead), which maybe is not something that userland should ever tho and just stick to mutexes?
after a few interrupt handler instructions, the first ERET instruction exits the handler and comes back directly to the instruction after the WFE at PC 0x400080 == 0x40007c + 4
the execution of the interrupt handler woke up the core that was in WFE, and it now continues normal execution past the WFE
+Therefore, a WFE in userland is treated much like a busy loop by the Linux kernel: the kernel does not seem to try and explicitly make up room for other processes as would happen on a futex.
The following test checks that SEV events don’t wake up a futexes, running forever in case of success. In gem5 syscall emulation multithreading, this is crucial to prevent deadlocks:
+sev + 1: wfe + 2: ldaxr w1, [w0] + cbnz w1, %1b + stxr w1, w2, [w0] + cbnz w1, %2b+
It is the STXR from the unlock on another core that automatically wakes up the spinlock afterwards: https://stackoverflow.com/questions/32276313/how-is-a-spin-lock-woken-up-in-linux-arm64
+gem5 390a74f59934b85d91489f8a563450d8321b602d does not sleep on the first WFE on either syscall emulation or full system, because the code does:
We have exploreed a few Continuous integration solutions.
+We have explored a few Continuous integration solutions.
We haven’t setup any of them yet.
@@ -32354,7 +32493,7 @@ cd -This setup sucessfully built gem5 on every commit: .circleci/config.yml
+This setup successfully built gem5 on every commit: .circleci/config.yml
Enabling it is however blocked on: https://github.com/cirosantilli/linux-kernel-module-cheat/issues/79 so we disabled the builds on the web UI.
@@ -32570,6 +32709,15 @@ instructions 124346081a18f28e263c91362519ef550150b5c9d75fa3679 + 1
gem5 --arch aarch64 --gem5-build-id debug
10^5
32
2.528728 * 10^6
0.08
a18f28e263c91362519ef550150b5c9d75fa3679 + 1
gem5 --arch aarch64 -- --cpu-type MinorCPU --caches
10^6
31
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
glibc C pre-main userland/c/m5ops.c -O0
gem5 --arch aarch64 --userland-args e
1
2
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
glibc C pre-main userland/c/m5ops.c -O0
gem5 --arch aarch64 --userland-args e --gem5-build-type debug
1
2
1.26479 * 10^5
0.05
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
glibc C++ pre-main userland/cpp/m5ops.cpp -O0
gem5 --arch aarch64 --userland-args e
1
2
2.385012 * 10^6
1
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
glibc C++ pre-main userland/cpp/m5ops.cpp -O0
gem5 --arch aarch64 --userland-args e --gem5-build-type debug
1
25
2.385012 * 10^6
0.1
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
immediate exit userland/arch/aarch64/freestanding/linux/gem5_exit.S -O0
gem5 --arch aarch64
1
1
ab6f7331406b22f8ab6e2df5f8b8e464fb35b611
immediate exit userland/arch/aarch64/freestanding/linux/gem5_exit.S -O0
gem5 --arch aarch64 --gem5-build-type debug
1
1
First we build Dhrystone manually statically since dynamic linking is broken in gem5 as explained at: Section 10.7, “gem5 syscall emulation mode”.
TODO: move this section to our new custom dhrystone setup: Section 21.8.1, “Dhrystone”.
+TODO: move this section to our new custom dhrystone setup: Section 21.8.2, “Dhrystone”.
gem5 user mode: