Re: remote thread packet formats

[Michael Snyder <msnyder at cygnus dot com>]

Guys, please note that Cygnus never published or documented 
these thread messages.  They were an early internal effort, 
and you can see how complicated and awkward they are.  We
hope to replace them with a better-designed and documented
set.  I do not recommend that you use these.

Soon I will propose a new set of simpler query messages 
for thread info.

				Michael Snyder

Ellery D'Souza [4611] wrote:
> 
> Hi Stuart,
> 
> > Can anyone shed more light on the remote thread packet formats ???
> > I want to add thread support for a custom RTOS.
> >
> > For example what does GDB expect in response to the "qL" and "qP"
> > commands ???
> 
> I have deciphered the 'qL' command and have implemented it in
> our 'inhouse' RTOS.
> 
> I will try to explain the format of the 'qL' and 'qM' packets, but I might
> get it wrong.  (There is an example that follows the explanation).
> 
> The 'qL' command is used to query for a thread list.
> 
> Query packet format looks as follows:
> 
>     qL 'startflag':8 'threadcount':16 'nextthread':64
> 
>         'startflag' is either a '0' or '1'.  A '1' means this
>             is the first query for a thread list. When 'startflag'
>             is '0', this is not the first query, so we must use the
>             'nextthread' as the last thread we gave as reponse to the last
>             query packet.
> 
>         'threadcount' is the maximum number of threads the response
>             packet can have.
> 
>         'nextthread' is the argument to use in the 'argthread' for
>             the response thread, and is used if the 'startflag' is
>             set to '0'.
> 
> Response packet:
> 
>     qM 'count':16 'done':8 'argthread':64 'threadsX':64 'threadsX':64 ...
> 
>         'count' is the number of threads we are returning.
>         'done'is either '0' or '1' - '1' means there are no more threads
>              to list, (another query packet is not needed).
>         'argthread' is 'nextthread' from the query packet.
>         'threadsX' is the threadid's of the threads from the remote target.
> 
> Example:
> 
>         Thread ids : 0x50000001, 0x50000002, .... , 0x50000005
>         Assume current thread is 0x50000001.
> 
>         Query packet will look as follows (I'm using threadcount = 3 to
>         make the packet look smaller - the actual number is quite big.
> 
>         Query #1:
>             qL1030000000050000001
> 
>                 startflag   = 1
>                 threadcount = 3
>                 argthread   = 0x50000001
> 
>         Response #1:
>             qM0300000000050000001000000005000000100000000500000020000000050000003
> 
>                 count     = 3
>                 done      = 0
>                 argthread = 0x50000001
>                 thread1   = 0x50000001
>                 thread2   = 0x50000002
>                 thread3   = 0x50000003
> 
>         Query #2:
>             qL0030000000050000003
> 
>                 startflag   = 0
>                 threadcount = 3
>                 argthread   = 0x50000003
> 
>         Response #2:
>             qM021000000005000000300000000500000040000000050000005
> 
>                 count     = 2
>                 done      = 1
>                 argthread = 0x50000003
>                 thread1   = 0x50000004
>                 thread2   = 0x50000005
> 
> I think my example is better then my explanation.
> Please feel free to point out and correct anything that is wrong.
> 
> I did not attempt much with the 'qP' packet, the threads
> on our 'inhouse' RTOS does not that much relevant information for
> gdb.
> 
> You might want to check out the following two function in remote.c
> and the callers of said functions:
> 
>         remote_unpack_thread_info_response
>         pack_threadinfo_request
> 
> --
> Ellery D'Souza
> edsouza@glenayre.com