1 files changed, 0 insertions, 94 deletions
diff --git a/gitlab/issues_text/target_missing/host_missing/accel_missing/1489 b/gitlab/issues_text/target_missing/host_missing/accel_missing/1489
deleted file mode 100644
index 96f7d5c53..000000000
--- a/gitlab/issues_text/target_missing/host_missing/accel_missing/1489
+++ /dev/null
@@ -1,94 +0,0 @@
-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.