MI -thread-list-ids output issue

MI -thread-list-ids output issue

[Vladimir Prus]

Hello!

At the moment, the response to -thread-list-ids looks like this:

  ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},


The grammar says that {} is a tuple, but not that all fields in the tuple
have the same name, so it can be only indexed by integer. While this is
allowed by the grammar, it's pretty inconvenient.

Essentially this will require me to add, in MI parser I use, special
operation "treat this as list, even though it looks like a tuple", which is
pretty nasty.

Maybe, it's still possible to change this output to be:

  ^done,thread-ids=["3","2","1"]

Or, if changing the existing output is deemed impossible even in this case,
what about:

  ^done,threads=["3", "2", "1"],
        thread-ids={thread-id="3",thread-id="2",thread-id="1"},

?

- Volodya

Re: MI -thread-list-ids output issue

[Bob Rossi]

On Thu, Feb 16, 2006 at 06:48:01PM +0300, Vladimir Prus wrote:
> 
> Hello!
> 
> At the moment, the response to -thread-list-ids looks like this:
> 
>   ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},
> 
> 
> The grammar says that {} is a tuple, but not that all fields in the tuple
> have the same name, so it can be only indexed by integer. While this is
> allowed by the grammar, it's pretty inconvenient.
> 
> Essentially this will require me to add, in MI parser I use, special
> operation "treat this as list, even though it looks like a tuple", which is
> pretty nasty.
> 
> Maybe, it's still possible to change this output to be:
> 
>   ^done,thread-ids=["3","2","1"]
> 
> Or, if changing the existing output is deemed impossible even in this case,
> what about:
> 
>   ^done,threads=["3", "2", "1"],
>         thread-ids={thread-id="3",thread-id="2",thread-id="1"},

Do you have a small C example I can use to generate this output with
GDB? I would like to use the parser i have written to see if I have the
same problem you have.

Also, you wouldn't be able to change the output of MI in a non-backwards
compatible way unless a new major version of MI is released. Also, even
then, it's probably a bad idea.

Bob Rossi

Re: MI -thread-list-ids output issue

[Daniel Jacobowitz]

On Thu, Feb 16, 2006 at 10:56:06AM -0500, Bob Rossi wrote:
> Do you have a small C example I can use to generate this output with
> GDB? I would like to use the parser i have written to see if I have the
> same problem you have.

Try any threaded program from gdb.threads.

-thread-list-ids
^done,thread-ids={thread-id="6",thread-id="5",thread-id="4",thread-id="3",thread-id="2",thread-id="1"},number-of-threads="6"

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI -thread-list-ids output issue

[Vladimir Prus]

On Thursday 16 February 2006 18:56, Bob Rossi wrote:
> On Thu, Feb 16, 2006 at 06:48:01PM +0300, Vladimir Prus wrote:
> > Hello!
> >
> > At the moment, the response to -thread-list-ids looks like this:
> >
> >   ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},
> >
> >
> > The grammar says that {} is a tuple, but not that all fields in the tuple
> > have the same name, so it can be only indexed by integer. While this is
> > allowed by the grammar, it's pretty inconvenient.
> >
> > Essentially this will require me to add, in MI parser I use, special
> > operation "treat this as list, even though it looks like a tuple", which
> > is pretty nasty.
> >
> > Maybe, it's still possible to change this output to be:
> >
> >   ^done,thread-ids=["3","2","1"]
> >
> > Or, if changing the existing output is deemed impossible even in this
> > case, what about:
> >
> >   ^done,threads=["3", "2", "1"],
> >         thread-ids={thread-id="3",thread-id="2",thread-id="1"},
>
> Do you have a small C example I can use to generate this output with
> GDB? I would like to use the parser i have written to see if I have the
> same problem you have.

Sure:

  http://websvn.kde.org/branches/work/kdevelop-debugger-mi/tests/threads/

The .cpp extension does not matter -- it's C subset.

The session is:

    -break-insert thread
    ^done,bkpt={number="1",type="breakpoint",disp="keep",
	enabled="y",addr="0x080484ea",func="thread(void*)",
	file="threads.cpp",line="6",times="0"}
    (gdb)
    -exec-run
    ^running
    (gdb)
    ~"[Thread debugging using libthread_db enabled]\n"
    ~"[New Thread -1211476288 (LWP 8708)]\n"
    ~"[New Thread -1211479120 (LWP 8726)]\n"
    ~"[New Thread -1219871824 (LWP 8727)]\n"
    ~"[Switching to Thread -1211479120 (LWP 8726)]\n"
    *stopped,reason="breakpoint-hit",bkptno="1",thread-id="2",
    frame={addr="0x080484ea",func="thread",args=[],file="threads.cpp",
    fullname="........../threads.cpp",
    line="6"}
    (gdb)
    -thread-list-ids
    ^done,thread-ids={thread-id="3",thread-id="2",thread-id="1"},
    number-of-threads="3"
    (gdb)

> Also, you wouldn't be able to change the output of MI in a non-backwards
> compatible way unless a new major version of MI is released. Also, even
> then, it's probably a bad idea.

It might be good idea to start drafting all changes for a new MI version. Not 
that I understand why to change MI if I have to workaround all issues in 
current gdb/MI anyway :-/

- Volodya