summary refs log tree commit diff stats
path: root/gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml
diff options
context:
space:
mode:
Diffstat (limited to 'gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml')
-rw-r--r--gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml119
1 files changed, 0 insertions, 119 deletions
diff --git a/gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml b/gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml
deleted file mode 100644
index b9fb2bed9..000000000
--- a/gitlab/issues/target_sparc/host_missing/accel_TCG/2385.toml
+++ /dev/null
@@ -1,119 +0,0 @@
-id = 2385
-title = "sparc: SIGILL stepping over `std` in gdb"
-state = "opened"
-created_at = "2024-06-07T21:44:15.092Z"
-closed_at = "n/a"
-labels = ["accel: TCG", "target: sparc"]
-url = "https://gitlab.com/qemu-project/qemu/-/issues/2385"
-host-os = "Ubuntu Linux 22.04 (6.5.0-35-generic)"
-host-arch = "x86_64"
-qemu-version = "8.2.94 (v9.0.0-rc4)"
-guest-os = "Solaris 9"
-guest-arch = "sparc"
-description = """Certain cases of single-stepping thru the `std` store double-word instruction causes SIGILL fatal trap, while normal execution of the program is fine. Unfortunately I do not have access to real SPARC hardware so I cannot attest whether this is an emulation issue or not.
-
-My previous bugfix #2281 fixed any single-stepping in a debugger from panicking the kernel, associated with the `lda` on ASI_USERTXT in the `default_fuword32` function. I suspect further bugs like this could be related somehow. Perhaps a different instruction is used for the 64-bit access that needs a similar fix.
-
-This problem was experienced while testing some shell-spawning assembly:
-```
--bash-4.3$ cat test.s
-.section ".text"
-.global main
-main:   
-        sethi  %hi(0x2f626800), %l6
-        or  %l6, 0x16e, %l6     ! 0x2f62696e
-        sethi  %hi(0x2f6b7000), %l7
-        or  %l7, 0x368, %l7     ! 0x2f6b7368
-        and  %sp, %sp, %o0
-        add  %sp, 0xc, %o1
-        xor  %o2, %o2, %o2
-        add  %sp, 0x14, %sp
-        std  %l6, [ %sp + -20 ]
-        clr  [ %sp + -12 ]
-        st  %sp, [ %sp + -8 ]
-        clr  [ %sp + -4 ]
-        mov  0x3b, %g1
-        ta  8
-        xor  %o7, %o7, %o0
-        mov  1, %g1
-        ta  8
-```
-
-```
--bash-4.3$ gcc test.s -o test
--bash-4.3$ ./test
-$ echo HELLO
-HELLO
-$ exit
-```
-
-As you can see the program works when ran directly from the shell, but when single-stepping in gdb, a SIGILL (illegal instruction) trap occurs
-```
--bash-4.3$ gdb test
-GNU gdb (GDB) 7.4.1
-[...]
-(gdb) disas main
-Dump of assembler code for function main:
-   0x0001061c <+0>:     sethi  %hi(0x2f626800), %l6
-   0x00010620 <+4>:     or  %l6, 0x16e, %l6     ! 0x2f62696e
-   0x00010624 <+8>:     sethi  %hi(0x2f6b7000), %l7
-   0x00010628 <+12>:    or  %l7, 0x368, %l7     ! 0x2f6b7368
-   0x0001062c <+16>:    and  %sp, %sp, %o0
-   0x00010630 <+20>:    add  %sp, 0xc, %o1
-   0x00010634 <+24>:    xor  %o2, %o2, %o2
-   0x00010638 <+28>:    add  %sp, 0x14, %sp
-   0x0001063c <+32>:    std  %l6, [ %sp + -20 ]
-   0x00010640 <+36>:    clr  [ %sp + -12 ]
-   0x00010644 <+40>:    st  %sp, [ %sp + -8 ]
-   0x00010648 <+44>:    clr  [ %sp + -4 ]
-   0x0001064c <+48>:    mov  0x3b, %g1
-   0x00010650 <+52>:    ta  8
-   0x00010654 <+56>:    xor  %o7, %o7, %o0
-   0x00010658 <+60>:    mov  1, %g1
-   0x0001065c <+64>:    ta  8
-End of assembler dump.
-(gdb) b main
-Breakpoint 1 at 0x1061c
-(gdb) r
-Starting program: /export/home/bazz/iob/test 
-
-Breakpoint 1, 0x0001061c in main ()
-(gdb) si
-0x00010620 in main ()
-(gdb) 
-0x00010624 in main ()
-[...]
-Program received signal SIGILL, Illegal instruction.
-0x0001063c in main ()
-```
-
-However, if I continue execution _over_ the `std` instruction, the SIGILL does not occur. it will get to the usual SIGTRAP after execve,
-but then complains about memory accesses that I've never seen before.
-```
-(gdb) r
-Starting program: /export/home/bazz/iob/test 
-
-Breakpoint 1, 0x0001061c in main ()
-(gdb) c
-Continuing.
-
-Program received signal SIGTRAP, Trace/breakpoint trap.
-0xef783af4 in _rt_boot () from /usr/lib/ld.so.1
-(gdb) c
-Continuing.
-Cannot access memory at address 0x2800007
-Cannot access memory at address 0x2800003
-(gdb) c
-Continuing.
-Cannot access memory at address 0x2800007
-Cannot access memory at address 0x2800003
-(gdb) c
-Continuing.
-$ 
-```
-
-It does eventually get a shell though.
-
-On mdb, instead of single-stepping into a SIGILL, everything goes unresponsive after stepping the `std` instruction. Then I have to kill mdb."""
-reproduce = "n/a"
-additional = "n/a"