Re: remote thread packet formats

Re: remote thread packet formats

[Ellery D'Souza [4611]]

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
From brendan@dgs.monash.edu.au Wed Aug 25 16:48:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: gdb <gdb@sourceware.cygnus.com>, "Insight (GDB GUI)" <insight@sourceware.cygnus.com>, Cross-GCC <crossgcc@cygnus.com>
Subject: Insight/GDB: ocd reg command not available.
Date: Wed, 25 Aug 1999 16:48:00 -0000
Message-id: <37C480DC.FEE52EAF@dgs.monash.edu.au>
X-SW-Source: 1999-q3/msg00234.html
Content-length: 390

I have used a beta version of gdb (thanks to Scott Howard) for
powerpc-eabi which had the "ocd
reg" command to set SPRs.  This command does not appear in Insight.

Is this command officially part of GDB or is there another way to set
SPRs
for powerpc processors.

Do the Insight snaphots use the latest versions of GDB ?  (latest
released versions or latest snapshots ?).

Brendan Simon.