From dee4dcba78baf712cab403d47d9db319ab7f95d6 Mon Sep 17 00:00:00 2001
From: Christian Krinitsin <mail@krinitsin.com>
Date: Thu, 3 Jul 2025 19:39:53 +0200
Subject: restructure results

---
 results/classifier/zero-shot/118/debug/2279 | 55 +++++++++++++++++++++++++++++
 1 file changed, 55 insertions(+)
 create mode 100644 results/classifier/zero-shot/118/debug/2279

(limited to 'results/classifier/zero-shot/118/debug/2279')

diff --git a/results/classifier/zero-shot/118/debug/2279 b/results/classifier/zero-shot/118/debug/2279
new file mode 100644
index 00000000..46ddfd67
--- /dev/null
+++ b/results/classifier/zero-shot/118/debug/2279
@@ -0,0 +1,55 @@
+debug: 0.954
+graphic: 0.951
+register: 0.902
+ppc: 0.847
+device: 0.832
+performance: 0.828
+architecture: 0.803
+semantic: 0.784
+peripherals: 0.780
+network: 0.762
+hypervisor: 0.708
+vnc: 0.707
+risc-v: 0.703
+files: 0.690
+socket: 0.685
+assembly: 0.678
+x86: 0.631
+permissions: 0.626
+PID: 0.616
+kernel: 0.605
+arm: 0.590
+VMM: 0.581
+mistranslation: 0.560
+TCG: 0.525
+user-level: 0.522
+KVM: 0.506
+i386: 0.499
+boot: 0.462
+virtual: 0.418
+
+Debugging with Lauterbach Trace32 -> Cortex-A76, no SP register update
+Description of problem:
+We do not see changes in the SP_EL1 register value when debugging the QEMU application with Lauterbach Trace32.
+Steps to reproduce:
+1. Compile bare metal code that uses push and pop instructions (stack).
+2. Run QEMU with bare metal code.
+3. Connect via Lauterbach Trace32 and check the displayed SP register value.
+Additional information:
+![T32_badA76_SP_reg_display](/uploads/e6af1ac3e32072274089e6dc0cdf0266/T32_badA76_SP_reg_display.png)
+This is a screenshot from QEMU 8.0.0, but updating to QEMU 8.2.0 does not resolve the problem.
+
+I have discussed this with Lauterbach Trace32 support with these results:
+- Trace32 uses RSP protocol `p` packets to read some registers, including SP_EL1. GDB seems to use `g` packet.
+- QEMU responds to `p` packet with an invalid value, which causes Trace32 to display invalid value.
+
+Some related RSP protocol logs from Trace32.
+![T32_sp_1](/uploads/cbe34d19d3ede30549e6c4d781bb6630/T32_sp_1.png)
+![T32_sp_2](/uploads/73e22dbf83ec00b939077dfeb7bfa208/T32_sp_2.png)
+
+Different part of RSP protocol log:
+```
+Sending packet: $p20#d2 ...
+receiving packet: ec00004000000000
+```
+So it looks like Trace32 can receive different values that zero as response to `p` packet.
-- 
cgit v1.2.3