Re: Don't try to report resumed thread it the thread list is empty.

[Pedro Alves <pedro at codesourcery dot com>]

A Saturday 05 July 2008 18:58:29, Vladimir Prus wrote:
> I've checked in the below to make GDB not assert in MI mode on
> targets where single-threaded programs have zero threads in the
> GDB thread table.
>

FYI, running the MI testsuite on a target that doesn't register
the main thread in ST programs, has failures that look like:

-exec-continue
^running
*running
(gdb) 
*stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"}
(gdb) 
FAIL: gdb.mi/mi2-var-display.exp: continue to do_special_tests (failed to 
resume)

I believe the issue is that in lib/mi-support.exp, *running matching assumes
there is -thread-id field
 
-re "220\\^running\[\r\n\]+\\*running,thread-id=\"\[^\"\]+\"\r\n$mi_gdb_prompt$" 
{}

I notice that there are other places that are outputing -thread-id="0", e.g.:

*stopped,reason="breakpoint-hit",disp="keep",bkptno="2",thread-id="0",frame={addr="0x000087e0",func="do_special_tests",args=[],file="../../../src/gdb/testsuite/gdb.mi/var-cmd.c",fullname="/home/pedro/gdb/monitor_always_a_thread/src/gdb/testsuite/gdb.mi/var-cmd.c",line="319"}
(gdb) 

So maybe we should make this consistent, and output -thread-id="0"
in *running as well?

-- 
Pedro Alves