diff options
Diffstat (limited to 'gitlab/issues_text/target_sparc/host_missing/accel_TCG')
7 files changed, 0 insertions, 417 deletions
diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 deleted file mode 100644 index 971b0ce1c..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/1771 +++ /dev/null @@ -1,33 +0,0 @@ -Missing CASA instruction handling for SPARC qemu-user -Description of problem: -Qemu-sparc does not handle the CASA instruction, even if the selected CPU (in this case, LEON3) support it. -Steps to reproduce: -1. Launch a program that use CASA instruction (any program, also "ls" on a recent glibc [>=2.31]) -2. qemu-sparc will raise "Illegal instruction" -Additional information: -The following patch remove the missing handling, but it needs asi load/store that is not implemented for sparc32 user-space. - -``` -diff -urp qemu-20230327.orig/target/sparc/translate.c qemu-20230327/target/sparc/translate.c ---- qemu-20230327.orig/target/sparc/translate.c 2023-03-27 15:41:42.000000000 +0200 -+++ qemu-20230327/target/sparc/translate.c 2023-04-01 15:24:18.293176711 +0200 -@@ -5521,7 +5522,7 @@ static void disas_sparc_insn(DisasContex - case 0x37: /* stdc */ - goto ncp_insn; - #endif --#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) -+//#if !defined(CONFIG_USER_ONLY) || defined(TARGET_SPARC64) - case 0x3c: /* V9 or LEON3 casa */ - #ifndef TARGET_SPARC64 - CHECK_IU_FEATURE(dc, CASA); -@@ -5529,8 +5530,8 @@ static void disas_sparc_insn(DisasContex - rs2 = GET_FIELD(insn, 27, 31); - cpu_src2 = gen_load_gpr(dc, rs2); - gen_cas_asi(dc, cpu_addr, cpu_src2, insn, rd); -+//#endif - break; --#endif - default: - goto illegal_insn; - } -``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 deleted file mode 100644 index 9e7869cf2..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2385 +++ /dev/null @@ -1,107 +0,0 @@ -sparc: SIGILL stepping over `std` in gdb -Description of problem: -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. diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 deleted file mode 100644 index 1e1d8be99..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2773 +++ /dev/null @@ -1,60 +0,0 @@ -qemu-system-sparc64 sometimes generates endless loops -Description of problem: -Sometimes emulation "stops" in a busy loop hogging 1 cpu completely. -gdb says: - -``` -0x00007d5805460ac5 in code_gen_buffer () -(gdb) info thread - Id Target Id Frame -* 1 LWP 9166 of process 12669 "" 0x00007d5805460ac5 in code_gen_buffer () - 2 LWP 19293 of process 12669 "" 0x00007d584680803a in ____sigtimedwait50 - () from /usr/lib/libc.so.12 - 3 LWP 20202 of process 12669 "" 0x00007d58468249ba in ___lwp_park60 () - from /usr/lib/libc.so.12 - 4 LWP 12669 of process 12669 "" 0x00007d58467b72ca in _sys___pollts50 () - from /usr/lib/libc.so.12 -(gdb) up -#1 0x00000000007b3a0f in cpu_tb_exec (cpu=cpu@entry=0x7d58041ac680, - itb=<optimized out>, tb_exit=tb_exit@entry=0x7d58037ffde8) - at ../accel/tcg/cpu-exec.c:458 -458 ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr); - -(gdb) down -#0 0x00007d5805460ac5 in code_gen_buffer () -(gdb) x/16i $pc -=> 0x7d5805460ac5 <code_gen_buffer+19401368>: mov %r15,0x68(%rbp) - 0x7d5805460ac9 <code_gen_buffer+19401372>: xor %r12,%r14 - 0x7d5805460acc <code_gen_buffer+19401375>: mov %r14,0x80(%rbp) - 0x7d5805460ad3 <code_gen_buffer+19401382>: mov %r12,%rbx - 0x7d5805460ad6 <code_gen_buffer+19401385>: mov %rbx,0x70(%rbp) - 0x7d5805460ada <code_gen_buffer+19401389>: mov %r12,0x78(%rbp) - 0x7d5805460ade <code_gen_buffer+19401393>: mov %r14,%r12 - 0x7d5805460ae1 <code_gen_buffer+19401396>: shr $0x20,%r12 - 0x7d5805460ae5 <code_gen_buffer+19401400>: and $0x1,%r12d - 0x7d5805460ae9 <code_gen_buffer+19401404>: dec %r12 - 0x7d5805460aec <code_gen_buffer+19401407>: and %rbx,%r12 - 0x7d5805460aef <code_gen_buffer+19401410>: mov %r12d,%ebx - 0x7d5805460af2 <code_gen_buffer+19401413>: movb $0x1,-0x4(%rbp) - 0x7d5805460af6 <code_gen_buffer+19401417>: cmp %r13,%rbx - 0x7d5805460af9 <code_gen_buffer+19401420>: - je 0x7d5805460b20 <code_gen_buffer+19401459> - 0x7d5805460aff <code_gen_buffer+19401426>: - jmp 0x7d5805460b04 <code_gen_buffer+19401431> -(gdb) list -453 if (qemu_loglevel_mask(CPU_LOG_TB_CPU | CPU_LOG_EXEC)) { -454 log_cpu_exec(log_pc(cpu, itb), cpu, itb); -455 } -456 -457 qemu_thread_jit_execute(); -458 ret = tcg_qemu_tb_exec(cpu_env(cpu), tb_ptr); -459 cpu->neg.can_do_io = true; -460 qemu_plugin_disable_mem_helpers(cpu); -461 /* -462 * TODO: Delay swapping back to the read-write region of the TB -``` -Steps to reproduce: -Unfortunately I have not been able to find a way to reliably reproduce this. -Happens "often" to me, but not always. - -If you have any idea (like: what traces to enable) how to debug this I'll try to gather more information diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 deleted file mode 100644 index f6b025c39..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2775 +++ /dev/null @@ -1,134 +0,0 @@ -internal assertion failure in sparc64 codegen: translate.c:5695:sparc_tr_insn_start: code should not be reached -Description of problem: -qemu crashes with internal assertion: - -ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached -Steps to reproduce: -1. boot emulated NetBSD/sparc64 system -2. cd /usr/tests && atf-run|atf-report - -not 100% reproducable, but happens often -Additional information: -last output: -``` -IN: -0x4102ce80: sethi %hi(0x29e0000), %g1 -0x4102ce84: b,a 0x40d78220 - ----------------- -IN: -0x41029fc0: sethi %hi(0x1e30000), %g1 -0x41029fc4: b,a 0x40e9ccc0 - ----------------- -IN: -0x4102b5e0: sethi %hi(0x23b8000), %g1 -0x4102b5e4: b,a 0x40e9dc20 - ----------------- -IN: -0x4102a6e0: sethi %hi(0x1ff8000), %g1 -0x4102a6e4: b,a 0x40e9cbc0 - ----------------- -IN: -0x410230e0: sethi %hi(0x278000), %g1 -0x410230e4: b,a 0x40e25d60 - ----------------- -IN: -0x41026920: sethi %hi(0x1088000), %g1 -0x41026924: b,a 0x40d77da0 - ----------------- -IN: -0x41024140: sethi %hi(0x690000), %g1 -0x41024144: b,a 0x40e25f00 - ----------------- -IN: -0x00245c20: sethi %hi(0xc8000), %g1 -0x00245c24: sethi %hi(0x40d77c00), %g1 -0x00245c28: jmp %g1 + 0x1a0 ! 0x40d77da0 -0x00245c2c: nop - ----------------- -IN: -0x00245ba0: sethi %hi(0xa8000), %g1 -0x00245ba4: b,a %xcc, 0x245920 - ----------------- -IN: -0x00245ba0: sethi %hi(0xa8000), %g1 -0x00245ba4: sethi %hi(0x40d76c00), %g1 -0x00245ba8: jmp %g1 + 0x80 ! 0x40d76c80 -0x00245bac: nop - ----------------- -IN: -0x00245e60: sethi %hi(0x158000), %g1 -0x00245e64: b,a %xcc, 0x245920 - ----------------- -IN: -0x00245e60: sethi %hi(0x158000), %g1 -0x00245e64: sethi %hi(0x40d76400), %g1 -0x00245e68: jmp %g1 + 0x260 ! 0x40d76660 -0x00245e6c: nop - ----------------- -IN: -0x002465a0: sethi %hi(0x328000), %g1 -0x002465a4: sethi %hi(0x40d69000), %g1 -0x002465a8: jmp %g1 + 0x198 ! 0x40d69198 -0x002465ac: nop - -** -ERROR:../target/sparc/translate.c:5695:sparc_tr_insn_start: code should not be reached -``` - -gdb says: -``` -#0 0x000079343d6ebbfa in _lwp_kill () from /usr/lib/libc.so.12 -#1 0x000079343d6f7034 in abort () - at /home/martin/current/src/lib/libc/stdlib/abort.c:74 -#2 0x000079343e06a03a in g_assertion_message[cold] () - from /usr/pkg/lib/libglib-2.0.so.0 -#3 0x000079343e03c719 in g_assertion_message_expr () - from /usr/pkg/lib/libglib-2.0.so.0 -#4 0x0000000000a23345 in sparc_tr_insn_start (dcbase=<optimized out>, - cs=<optimized out>) at ../target/sparc/translate.c:5695 -#5 0x0000000000aa932f in translator_loop (cpu=cpu@entry=0x7933fac3be40, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, - host_pc=host_pc@entry=0x7933f52a58f7, - ops=ops@entry=0xfac3c0 <sparc_tr_ops>, db=db@entry=0x7933fa5d3b80) - at ../accel/tcg/translator.c:152 -#6 0x0000000000a368ca in gen_intermediate_code (cs=cs@entry=0x7933fac3be40, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - max_insns=max_insns@entry=0x7933fa5d3d44, pc=pc@entry=1206519, - host_pc=host_pc@entry=0x7933f52a58f7) at ../target/sparc/translate.c:5816 -#7 0x0000000000aa7e90 in setjmp_gen_code (env=env@entry=0x7933fac3e5e0, - tb=tb@entry=0x79341ba52840 <code_gen_buffer+549308435>, - pc=pc@entry=1206519, host_pc=0x7933f52a58f7, - max_insns=max_insns@entry=0x7933fa5d3d44, ti=<optimized out>) - at ../accel/tcg/translate-all.c:278 -#8 0x0000000000aa835d in tb_gen_code (cpu=cpu@entry=0x7933fac3be40, - pc=pc@entry=1206519, cs_base=cs_base@entry=1206523, flags=2181038080, - cflags=cflags@entry=-16777216) at ../accel/tcg/translate-all.c:358 -#9 0x0000000000aa135b in cpu_exec_loop (cpu=cpu@entry=0x7933fac3be40, - sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:993 -#10 0x0000000000aa1788 in cpu_exec_setjmp (cpu=cpu@entry=0x7933fac3be40, - sc=sc@entry=0x7933fa5d3e80) at ../accel/tcg/cpu-exec.c:1039 -#11 0x0000000000aa1f8d in cpu_exec (cpu=cpu@entry=0x7933fac3be40) - at ../accel/tcg/cpu-exec.c:1065 -#12 0x0000000000abb53d in tcg_cpu_exec (cpu=cpu@entry=0x7933fac3be40) - at ../accel/tcg/tcg-accel-ops.c:78 -#13 0x0000000000abb6ae in mttcg_cpu_thread_fn (arg=arg@entry=0x7933fac3be40) - at ../accel/tcg/tcg-accel-ops-mttcg.c:95 -#14 0x0000000000c7f750 in qemu_thread_start (args=0x79343aef7520) - at ../util/qemu-thread-posix.c:541 -#15 0x000079343d98c145 in pthread__create_tramp (cookie=0x79343c583000) - at /home/martin/current/src/lib/libpthread/pthread.c:595 -#16 0x000079343d5d1310 in ?? () from /usr/lib/libc.so.12 -``` diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 deleted file mode 100644 index c77e9a5f8..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/2802 +++ /dev/null @@ -1,26 +0,0 @@ -Sparc: fdtox/fqtox instructions incorrectly select destination register -Description of problem: -This bug report is mostly for informational purposes as I will be posting a fix for the bug. - -The `fdtox` and `fqtox` instructions incorrectly select the destination register when the destination register is higher than `f31`. -Steps to reproduce: -1. Install Sparc cross compiler `gcc-12-sparc64-linux-gnu`(in Debian) -2. Compile the test program using `sparc64-linux-gnu-gcc-12 -m64 -o test_program -static test_program.c` -3. Run the test program using `qemu-sparc64-static ./test_program` -4. Expected output is 60. Prints 0 instead. -Additional information: -Test program to test the issue: - -```c -#include <stdio.h> - -int main(int argc, char** argv) { - long long truncated = 0; - __asm__("fdtox %0,%%f32\n\t" :: "f"(60.0)); - __asm__("fmovd %%f32,%0\n\t" : "=f"(truncated)); - printf("%lld\n", truncated); - return 0; -} -``` - -The issue is caused by the commit 0bba7572d4. Where certain changes were made in the way destination registers are selected(moving the DFPREG/QFPREG to decodetree). diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 deleted file mode 100644 index 30fa29364..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/740 +++ /dev/null @@ -1,27 +0,0 @@ -on single core Raspberry Pi, qemu-system-sparc appears to hang in bios -Description of problem: -I suspect it to be a race condition related to running on the slow single core Raspberry Pi, as I haven't managed to reproduce on x86 even when using taskset to tie qemu to a single core. - -The problem occurs about 4 out of 5 runs on qemu 5.2 (raspbian bullseye) and so far 100% of the time on qemu 6.1. - -About five seconds after start the sparc bios gets as far as `ttya initialized` and then appears to hang indefinitely. - -Instead, it should continue after about 3 more seconds with: -``` -Probing Memory Bank #0 32 Megabytes -Probing Memory Bank #1 Nothing there -Probing Memory Bank #2 Nothing there -Probing Memory Bank #3 Nothing there -``` - -See below for workaround. -Steps to reproduce: -1. Need a single core Raspberry Pi running raspbian, such as Raspberry Pi 1 or Zero -2. Download ss5.bin from https://github.com/andarazoroflove/sparc/raw/master/ss5.bin -3. Run the command: -``` -qemu-system-sparc -m 32 -bios ss5.bin -nographic -``` -After about 5 seconds of output it hangs at `ttya initialized` -Additional information: -## diff --git a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 b/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 deleted file mode 100644 index 38a2e4c28..000000000 --- a/gitlab/issues_text/target_sparc/host_missing/accel_TCG/847 +++ /dev/null @@ -1,30 +0,0 @@ -rdhpr %htstate unimplemented in translator -Description of problem: -I accidentally mixed up a copy of T1 and T2 sun4v firmwares and was able to trigger the following TCG assert ``tcg_reg_alloc_mov: Assertion `ts->val_type == TEMP_VAL_REG' failed.`` upon boot. - -Having discovered my mistake I was expecting the guest to crash at some point but without triggering an -assert. -Steps to reproduce: -1. Download the attached file bug.tar.gz and extract it - -2. Apply the following diff to update the UART address for the T2 firmware - -``` -diff --git a/hw/sparc64/niagara.c b/hw/sparc64/niagara.c -index ccad2c43a3..7af64bd50f 100644 ---- a/hw/sparc64/niagara.c -+++ b/hw/sparc64/niagara.c -@@ -51,7 +51,7 @@ typedef struct NiagaraBoardState { - - #define NIAGARA_PARTITION_RAM_BASE 0x80000000ULL - --#define NIAGARA_UART_BASE 0x1f10000000ULL -+#define NIAGARA_UART_BASE 0xfff0c2c000ULL - - #define NIAGARA_NVRAM_BASE 0x1f11000000ULL - #define NIAGARA_NVRAM_SIZE 0x2000 -``` - -3. Run `./qemu-system-sparc64 -M niagara -L ./bug/ -m 256 -nographic` -Additional information: - |