Alex Bennée <alex.ben...@linaro.org> writes:
> Richard Henderson <richard.hender...@linaro.org> writes:
>
>> The PSW_MASK_CC component of psw.mask was not handled properly
>> in the creation or restoration of signal frames.
>
> Still seeing issues running on s390x machine:
>
> 05:00:29 [ajb@qemu01:~/l/q/b/debug] s390x/signal-fixes|… 38 + retry.py -n
> 100 -c -- ./qemu-s390x ./tests/tcg/s390x-linux-user/signals
> ...
> ...
> Results summary:
> 0: 62 times (62.00%), avg time 2.253 (0.00 varience/0.00 deviation)
> -11: 38 times (38.00%), avg time 0.251 (0.00 varience/0.00 deviation)
> Ran command 100 times, 62 passes
>
> I don't get much from the backtrace, maybe the atomic triggered the seg?
>
> #0 0x0000000001016244 in vfprintf ()
> [Current thread is 1 (Thread 0x4001001910 (LWP 27308))]
> (gdb) bt
> #0 0x0000000001016244 in vfprintf ()
> #1 0x000000000101d484 in printf ()
> #2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at
> /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
> #3 0x0000000001003150 in start_thread (arg=0x4001001910) at
> pthread_create.c:463
> #4 0x0000000001035b40 in thread_start ()
> (gdb) frame 2
> #2 0x0000000001000b2e in background_thread_func (arg=0x10a3620) at
> /home/ajb/lsrc/qemu.git/tests/tcg/multiarch/signals.c:65
> 65 printf("thread%d: started\n", job->number);
> (gdb) info locals
> job = 0x10a3620
> (gdb) p job
> $1 = (ThreadJob *) 0x10a3620
> (gdb) p job->number
> $2 = 0
> (gdb) frame 0
> #0 0x0000000001016244 in vfprintf ()
> (gdb) x/5i $pc
> => 0x1016244 <vfprintf+1316>: asi 224(%r11),1
> 0x101624a <vfprintf+1322>: cgijne %r1,0,0x1017570 <vfprintf+6224>
> 0x1016250 <vfprintf+1328>: lg %r1,336(%r11)
> 0x1016256 <vfprintf+1334>: lghi %r3,37
> 0x101625a <vfprintf+1338>: aghik %r6,%r1,1
> (gdb) p/x $r11
> $3 = 0x4001000708
> (gdb) p/x $r11 + 224
> $4 = 0x40010007e8
> (gdb) x/1g $4
> 0x40010007e8: 0x0000000000000000
> (gdb)
>
> However running on x86 backend everything seems to be fine.
>
> Results summary:
> 0: 200 times (100.00%), avg time 2.255 (0.00 varience/0.00 deviation)
> Ran command 200 times, 200 passes
It's hard to desegregate the SEGVs we get during normal runs but a pass
followed by a fail shows:
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473bb1e address=40007ff000 w=1 oldset=0x00000000
shutting down after: 2000 signals
qemu: SIGSEGV pc=0x3fff484bd1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4848f1a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff47477f2 address=40007ff000 w=1 oldset=0x00000000
[Thread 0x3fffdff1780 (LWP 32928) exited]
[Inferior 1 (process 32928) exited normally]
(gdb) r
Starting program: /home/ajb/lsrc/qemu.git/builds/debug/qemu-s390x
./tests/tcg/s390x-linux-user/signals
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/s390x-linux-gnu/libthread_db.so.1".
[New Thread 0x3fffceff910 (LWP 32964)]
qemu: SIGSEGV pc=0x3fff4752f2a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471fa1e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff475c49c address=40007ff000 w=1 oldset=0x00000000
[New Thread 0x3fffdff0910 (LWP 32965)]
qemu: SIGSEGV pc=0x3fff4703b18 address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fffd812efe address=4001000000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471081e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4715ee6 address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff471a02a address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff472491e address=40007ff000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4725d1e address=4001000000 w=1 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff4730536 address=4001000000 w=0 oldset=0x00000000
qemu: SIGSEGV pc=0x3fff473171e address=40007ff000 w=1 oldset=0x00000000
[Thread 0x3fffdff0910 (LWP 32965) exited]
[Thread 0x3fffceff910 (LWP 32964) exited]
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
So something is going astray to 4001000000 which otherwise doesn't.
>
>>
>>
>> r~
>>
>>
>> Richard Henderson (5):
>> target/s390x: Expose load_psw and get_psw_mask to cpu.h
>> target/s390x: Do not modify cpu state in s390_cpu_get_psw_mask
>> target/s390x: Improve s390_cpu_dump_state vs cc_op
>> target/s390x: Use s390_cpu_{set_psw,get_psw_mask} in gdbstub
>> linux-user/s390x: Save and restore psw.mask properly
>>
>> target/s390x/cpu.h | 3 ++
>> target/s390x/internal.h | 5 --
>> linux-user/s390x/signal.c | 37 ++++++++++++--
>> target/s390x/cc_helper.c | 2 +-
>> target/s390x/excp_helper.c | 28 +++++-----
>> target/s390x/gdbstub.c | 15 +-----
>> target/s390x/helper.c | 101 ++++++++++++++++++++-----------------
>> target/s390x/sigp.c | 3 +-
>> 8 files changed, 110 insertions(+), 84 deletions(-)
--
Alex Bennée
