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

Vladimir Prus vladimir@codesourcery.com
Wed Jul 9 12:04:00 GMT 2008


On Wednesday 09 July 2008 14:31:21 Pedro Alves wrote:
> 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, 

For the record, which target did you test on?

> 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?

I'm not sure which way we want to make it consistent. Outputiing "thread-id" 
with a "I don't exist" value of thread id seems a little bit distasteful.
I guess I can modify regexp to make thread-id optional.

- Volodya



More information about the Gdb-patches mailing list