add gemma accelerator classification results

1 files changed, 95 insertions, 0 deletions

diff --git a/results/classifier/accel-gemma3:12b/kvm/1489 b/results/classifier/accel-gemma3:12b/kvm/1489
new file mode 100644
index 000000000..15b5dc76d
--- /dev/null
+++ b/results/classifier/accel-gemma3:12b/kvm/1489
@@ -0,0 +1,95 @@
+
+Breakpoints set at wrong addresses in `test-gdbstub.py` for some Linux kernels guest images
+Description of problem:
+The script `tests/guest-debug/test-gdbstub.py` for testing QEMU's GDB
+stub on Linux kernel guests sets breakpoints on `kernel_init()` and
+`wait_for_completion()`. As the script is coded, breakpoints are set
+(implicitly) not at the functions' start addresses, but at the end of
+the functions' prologues.
+
+For some Linux kernel builds in which `kernel_init()` and
+`wait_for_completion()` get compiled with a function prologue, the
+script fails to detect breakpoint hits in `check_hbreak()` and
+`check_break()` because it compares the stopped address (i.e. the end of
+the function's prologue) with the function's start address, and they
+differ. To observe the difference in GDB:
+
+```sh
+$ gdb -q --nx vmlinux
+Reading symbols from vmlinux...
+(gdb) b kernel_init
+Breakpoint 1 at 0xffff800008fbeb28: file init/main.c, line 1497.    # <- prologue start
+(gdb) b *kernel_init
+Breakpoint 2 at 0xffff800008fbeb18: file init/main.c, line 1491.    # <- function start
+```
+
+In my tests, the issue doesn't occur with standard Linux kernels builds
+(e.g. compiled on Linux hosts with GCC) because typically both
+`kernel_init()` and `wait_for_completion()` seem to be without
+prologues.
+Steps to reproduce:
+The issue has so far been encountered only with arm64 Linux kernel
+guests compiled on macOS arm64 with
+[mac-linux-kdk](https://github.com/GayPizzaSpecifications/mac-linux-kdk).
+
+1. Compile a recent arm64 Linux kernel on macOS arm64 with debugging
+   information (first `make defconfig`, then `make menuconfig` and set
+   `Kernel hacking / Compile-time checks and compiler options / Debug
+   information / Rely on toolchain's implicit default DWARF version`)
+
+    ```sh
+    $ file /tmp/linux-5.19/arch/arm64/boot/Image
+    /tmp/linux-5.19/arch/arm64/boot/Image: Linux kernel ARM64 boot executable Image, little-endian, 4K pages
+    $ file /tmp/linux-5.19/vmlinux
+    /tmp/linux-5.19/vmlinux: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), statically linked, BuildID[sha1]=bf9e422d48e0aded5859fe34d6de2c174ef3a20b, with debug_info, not stripped
+    ```
+
+2. Start QEMU waiting for GDB to connect:
+
+    ```sh
+    $ ./qemu-system-aarch64 -smp 1 -M virt -cpu cortex-a57 -kernel /tmp/linux-5.19/arch/arm64/boot/Image -append nokaslr -s -S
+    ```
+
+3. Execute the `test-gdbstub.py` script (as described in the script file
+   itself):
+
+    ```sh
+    $ gdb /tmp/linux-5.19/vmlinux -x tests/guest-debug/test-gdbstub.py
+    ```
+
+    The script then hangs.
+
+Tested both on a macOS host and a Linux host.
+Additional information:
+The proposed fix is to explicitly disable GDB's prologue decoder and set
+the two breakpoints at the functions' start addresses [by adding an
+asterisk before the function
+name](https://stackoverflow.com/a/31451340):
+
+```diff
+diff --git a/tests/guest-debug/test-gdbstub.py b/tests/guest-debug/test-gdbstub.py
+index 98a5df4d4..6202d17c3 100644
+--- a/tests/guest-debug/test-gdbstub.py
++++ b/tests/guest-debug/test-gdbstub.py
+@@ -31,7 +31,7 @@ def check_step():
+ def check_break(sym_name):
+     "Setup breakpoint, continue and check we stopped."
+     sym, ok = gdb.lookup_symbol(sym_name)
+-    bp = gdb.Breakpoint(sym_name)
++    bp = gdb.Breakpoint("*%s" % (sym_name))
+
+     gdb.execute("c")
+
+@@ -48,7 +48,7 @@ def check_break(sym_name):
+ def check_hbreak(sym_name):
+     "Setup hardware breakpoint, continue and check we stopped."
+     sym, ok = gdb.lookup_symbol(sym_name)
+-    gdb.execute("hbreak %s" % (sym_name))
++    gdb.execute("hbreak *%s" % (sym_name))
+     gdb.execute("c")
+
+     # hopefully we came back
+```
+
+This change shouldn't impact the Linux kernel guests for which the
+script is already working as intended.