Re: [PATCH v2 00/23] All-stop on top of non-stop

[Pedro Alves <palves at redhat dot com>]

On 04/08/2015 10:45 AM, Yao Qi wrote:
> Pedro Alves <palves@redhat.com> writes:
> 
>> While v1 had only been tested on x86-64 GNU/Linux, v2 was tested on:
>>
>>      x86-64 GNU/Linux
>>      x86-64 GNU/Linux on top of software single-step branch
>>      PPC64 GNU/Linux
>>      S/390 GNU/Linux
> 
> Hi Pedro,
> I tested this patch series on arm GNU/Linux, both native and gdbserver.
> Overall, the results look pretty good, here are some fails
> exposed/caused by this series.  I'd like to post them first today and
> take a look at this series then.
> 
> 1, on gdbserver,
> -UNSUPPORTED: gdb.mi/mi-dprintf.exp: send dprintf to target
> +FAIL: gdb.mi/mi-dprintf.exp: mi expect stop (unknown output after running)
> +FAIL: gdb.mi/mi-dprintf.exp: mi 1st dprintf, agent (unknown output after running)
> +FAIL: gdb.mi/mi-dprintf.exp: mi info dprintf second time
> +FAIL: gdb.mi/mi-dprintf.exp: mi 2nd dprintf, agent (timeout)
> 
> BEFORE:
> 220-exec-continue^M
> 220^error,msg="Warning:\nCannot insert breakpoint 3: Target doesn't support breakpoints that have target side commands.\nCannot insert breakpoint 4: Target doesn't support breakpoints that have target side commands.\n"^M
> (gdb) ^M
> UNSUPPORTED: gdb.mi/mi-dprintf.exp: send dprintf to target
> 
> AFTER:
> 220-exec-continue^M
> 220^running^M
> *running,thread-id="all"^M
> (gdb) ^M
> 
> I think that is the mi-dprintf.exp issue, which doesn't detect target
> dprintf support correctly.

Sounds like it.  Though I can't see how the series could have
changed the result.  Maybe it's racy.  Passes for me with
x86_64 gdbserver with and without software single-step.

> 
> 2, on gdbserver,
> +FAIL: gdb.threads/thread-find.exp: find lwp id 6
> +FAIL: gdb.threads/thread-find.exp: find lwp id 5
> +FAIL: gdb.threads/thread-find.exp: find lwp id 4
> +FAIL: gdb.threads/thread-find.exp: find lwp id 3
> +FAIL: gdb.threads/thread-find.exp: find lwp id 2
> +FAIL: gdb.threads/thread-find.exp: find lwp id 1
> thread find 18340^M
> No threads match '18340'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 6
> thread find 18339^M
> No threads match '18339'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 5
> thread find 18338^M
> No threads match '18338'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 4
> thread find 18337^M
> No threads match '18337'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 3
> thread find 18336^M
> No threads match '18336'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 2
> thread find 18333^M
> No threads match '18333'^M
> (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 1
> 

How odd.  Passes for me with x86_64 gdbserver+sss.

The "find lwp id" messages indicate that this:

if { [info exists lwp6] } then {
    gdb_test "echo $lwp6\\n" "$lwp6" "got lwp ids"
}

... was reached.  Are you running the testsuite with two boards
at the same time?  In that case, I'd guess that the test first
ran against the native target, which left $lwp6 set, and then
it run against gdbserver, with $lwp6 stale.

> Maybe, thread list in GDB side is out of date?

Don't think so, there are a bunch of "info threads" calls.

> 
> 3, on native,
> -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4
> +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4
> 
> continue^M
> Continuing.^M
> ^M
> Program received signal SIGSEGV, Segmentation fault.^M
> 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M
> (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4

Most of the SIGSEGV/SIGILL/SIGBUS inferior crashes I saw were
due to a displaced stepping bug.  Force disabling displaced
stepping with "set displaced off" usually "fixes" it.  The next
step I would usually take would be to run the test manually, with
"set debug infrun 1" + "set debug displaced 1" + "set debug lin-lwp 1".

Thanks,
Pedro Alves