diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-05 20:00:38 +0200 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-05 20:00:38 +0200 |
| commit | 96049c939b1916d80532630d63c14e04d5244f1d (patch) | |
| tree | 7fb9df428f074078e714f1e038210cdff887185a /results/classifier/user-mode-bugs/2248 | |
| parent | 40bbb77d4dfebff4f99c2f90b2c0db737b0ecc5a (diff) | |
| download | qemu-analysis-96049c939b1916d80532630d63c14e04d5244f1d.tar.gz qemu-analysis-96049c939b1916d80532630d63c14e04d5244f1d.zip | |
lock user-mode and semantic-bugs
Diffstat (limited to 'results/classifier/user-mode-bugs/2248')
| -rw-r--r-- | results/classifier/user-mode-bugs/2248 | 38 |
1 files changed, 38 insertions, 0 deletions
diff --git a/results/classifier/user-mode-bugs/2248 b/results/classifier/user-mode-bugs/2248 new file mode 100644 index 000000000..204c11506 --- /dev/null +++ b/results/classifier/user-mode-bugs/2248 @@ -0,0 +1,38 @@ + + +qemu-aarch64: wrong execution result when executing the code +Description of problem: +The following aarch64 code results in the wrong execution result `4611686018427387903`, which is `0x3fffffffffffffff`. (The correct result is `-1`) The bug seems to be introduced in between v8.1.5 and v8.2.1 since the results are correct in v8.1.5. + +```c +// foo.c +#include <stdio.h> +#include <stdint.h> + +int64_t callme(size_t _1, size_t _2, int64_t a, int64_t b, int64_t c); + +int main() { + int64_t ret = callme(0, 0, 0, 1, 2); + printf("%ld\n", ret); + return 0; +} +``` + +```s +// foo.S +.global callme +callme: + cmp x2, x3 + cset x12, lt + and w11, w12, #0xff + cmp w11, #0x0 + csetm x14, ne + lsr x13, x14, x4 + sxtb x0, w13 + ret +``` +Steps to reproduce: +1. Build the code with `aarch64-linux-gnu-gcc foo.c foo.S -o foo` (`aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0`) +2. Run the code with `qemu-aarch64 -L /usr/aarch64-linux-gnu -E LD_LIBRARY_PATH=/usr/aarch64-linux-gnu/lib foo` and see the result +Additional information: +- Original discussion is held in [this wasmtime issue](https://github.com/bytecodealliance/wasmtime/issues/8233). Thanks to Alex Crichton for clarifying this bug. |