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

Pedro Alves
2015-10-19T16:48:40Z

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