Re: [PATCH 14/18] Implement TARGET_WAITKIND_NO_RESUMED in the remote protocol

[Pedro Alves <palves@redhat.com>]

On 10/19/2015 05:21 PM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> Testing with "maint set target-non-stop on" causes regressions in
>> tests that rely on TARGET_WAITKIND_NO_RESUMED, which isn't modelled on
>> the RSP.  In real all-stop, gdbserver detects the situation and
>> reporst error to GDB, and so the tests (e.g.,
>> gdb.threads/no-unwaited-for-left.exp) at fail quickly.  But with
>> "maint set target-non-stop on", GDB instead hangs forever waiting for
>> a stop reply that never comes, and so the tests take longer to time
>> out.
> 
> A quick comment here, we also need to get rid of
> setup_kfail "gdb/14618" "*-*-*" in gdb.threads/no-unwaited-for-left.exp,
> otherwise, we'll see 
> 
> KPASS: gdb.threads/no-unwaited-for-left.exp: continue stops when thread 2 exits (PRMS gdb/14618)
> KPASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits (PRMS gdb/14618)

Indeed, I'll add that.

> 
> gdb.threads/no-unwaited-for-left.exp also triggers a SIGSEGV in AArch64
> GDBserver, because current_thread is de-referenced, but it is NULL.
> 
> Program received signal SIGSEGV, Segmentation fault.
> inferior_regcache_data (inferior=inferior@entry=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/inferiors.c:259
> 259	/home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/inferiors.c: No such file or directory.
> (gdb) bt  
> #0  inferior_regcache_data (inferior=inferior@entry=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/inferiors.c:259
> #1  0x0000000000406138 in get_thread_regcache (thread=0x0, fetch=fetch@entry=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/regcache.c:31
> #2  0x00000000004204b8 in is_64bit_tdesc () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-aarch64-low.c:84
> #3  0x000000000042128c in aarch64_supports_z_point_type (z_type=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-aarch64-low.c:263
> #4  0x0000000000424c70 in linux_supports_z_point_type (z_type=<optimized out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/linux-low.c:5634
> #5  0x0000000000410fbc in z_type_supported (z_type=48 '0') at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/mem-break.c:918
> #6  check_gdb_bp_preconditions (z_type=z_type@entry=48 '0', err=0x40e3c8 <process_serial_event+1032>, err@entry=0x7ffffff1dc)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/mem-break.c:1009
> #7  0x0000000000412250 in delete_gdb_breakpoint (z_type=z_type@entry=48 '0', addr=4196920, size=0)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/mem-break.c:1081
> #8  0x000000000040e3c8 in process_serial_event () at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:4182
> #9  0x000000000040f754 in handle_serial_event (err=<optimized out>, client_data=<optimized out>)
>     at /home/yao/SourceCode/gnu/gdb/git/gdb/gdbserver/server.c:4312
> 
> Need to figure out what is the best fix.

Sounds like an issue similar to the one in patch #4 (and also patch #15).
I was thinking that we'll probably need to generalize a bit the fix in patch #4,
by adding a "set_general_process" function to gdbserver based on that
(naming mirrors gdb/remote.c's own set_general_process).

Thanks,
Pedro Alves