From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quality Quorum To: Andrew Cagney Cc: gdb@sourceware.cygnus.com Subject: Re: remote nits Date: Tue, 14 Dec 1999 06:47:00 -0000 Message-id: References: <3855F0D8.12905961@cygnus.com> X-SW-Source: 1999-q4/msg00502.html On Tue, 14 Dec 1999, Andrew Cagney wrote: > Quality Quorum wrote: > > > > Hi, > > > > I found more remote nits reading manual on the net and > > gdb-19990913/gdb/remote.c . Below is summary. > > > > A. Handling of Depreciated Elements > > > > It seems to me that debugger should never emit > > depreciated requests. 'qL' request is marked > > as depreciated in the document, however, there is > > code which will emit it. > > Its important to apreciate how GDB needs to continue to support existing > targets. While we don't want anyone to use QL (and wish it was replaced > with something better) that doesn't mean that it is reasonable to simply > pull that code. People in the field need to be given several years > notice and the chance to migrate to something better. it. I do appreciate and I do understand it, however, there is also a need in clear documentation. It seems to me that we have to use different term (which one ???) to describe things which are going to be replaced, however, are still in use. BTW, my general attitude is 'do not change anything, unless it is absolutely necessary', however, clean documentation, with clear migration part is essential in my view. > > Much of the thread code is in this situtation. > There is much more to the thread code than that. As far as I can see it looks as follows, (1)gdb uses 32-bit signed pid internally to identify thread, (2) remote machine uses the 64-bit address of the thread control block to identify the thread,(3)gdb side does conversion, (4) this conversion is not fully/cleanly implemented yet. There are three ways to address this issue: 1. Make target to convert its internal thread_ids into pids. Pro: (a)it provides nice abstract interface, (b) it is not that big a deal for a target to implement, (b) it allows for effective implementation of thread list feature, (c) it is fully compatible with all operations except 'qL' and 'qP' requests . Con: (a) it breaks 'qL' and 'qP' requests. (In my view this is a fatal problem for this approach). 2. Fully implement conversion on gdb side. Pro: (a) it provides thread_id which may have meaning for the person debugging the stuff, (b) it is trivial to implement on gdb side, (c) it does not break 'qL' and 'qP' requests. Con: (a) there are cases where it will break 'qC', 'T' - both cases and 'Hx' requests, (b) in many cases target side overhead similar to the case (1) will be required to properly implement thread list. 3. Fully implement conversion on gdb side with modifications: o Thread ids visible on the wire are 64-bit unsigned values o Thread id 0xffffffffffffffff means 'all-threads', if no threads are implemented this is the only thread visible to gbd (internally it matches to magic - 'all-thread' pid of 4200). o There are two formats to represent a thread_id on the wire. V-thread - byte encoded into 1-16 characters MSB first, with possibly omitted leading 0's, with 'all-threads' id encoded as '-xxxxxxxxxxx', where 'xxxxxxx' is any combination of 1-16 hex digits, with preferred form being '-1'. E.g. if(thread_id == XXX_VAL_THEADID_ALLTHREADS) { out_buf[0] = '-'; out_buf[1] = '1'; out_buf[2] = 0; } else { sprintf(out_buf, "%Lx", thread_id); } and F-thread - byte encoded into 16 characters MSB first, e.g. sprintf(out_buf, "%016Lx", thread_id);. o Requests 'Hx', 'T' and 'qC' use V-thread format, 'qP' and 'qL' use F-thread format. Comparing to (2) it has additional advantages (a) of being completely compatible with all existing implementations, while providing a clean migration path, (b) it will allow to use 'qL' and 'qP' requests without reinventing them. In my view (3) is a clear winner I am going to write formal document specifying protocol using this encoding during the day today. > > C. Requests Violating Protocol Principles > > > It seems to me that '!' is not that bad. At least one > > popular implementation I saw (gdbserver) will report last status > > in response to '!'. It seems that a low pain way to deal > > with it is to have local variable, say 'remoteforceextended'. > > If this variable is set then any response to '!' is considered > > a success, otherwise "" means no support, "OK" or status string > > mean support, everything else considered an error. > > You may want to study gdbserver more closely. The thing that it does is > change GDB servers behaviour. Strictly speaking both of those should be > controlled through ``[Qq]'' packets and ``!'' should be given the boot. It seems to me that we have widely used implementation (gdbserver) with sensible handling of '!', so in my view it is safe to make it default behavior with old behavior supported when some variable (e.g. extendedremoteforce) is set. > > It seems to me that 'D' could be depreciated: we can use 'c' > > followed by connection close instead - 'c' supposed to have exactly > > same effect and is required to be implemented. Another way is > > to define new detach request which will require stub to send > > reply before disconnecting. > > There is a good chance that nothing uses it. > However, what mechanism are you proposing that will allow GDB to > disconnect from one target programme and then connect to a second? 1. If there is no threads supported on the remote machine, then the topic is moot. 2. It there threads then the sequence could be 'Hc...' - set new control thread 'Hg...' - set new generic thread (whatever does it mean). 'xxxx' - set break point in the new control thread context 'c' - continue > > It is unclear from document that 'qRcmd' indeed allows responses > > starting from 'E', however there is a code handling this case > > in remote.c > > The normal response to Rcmd is a HEX encoded byte-stream. E is a hex > digit. ???????? As far as I understand the document normal response to Rcmd is a sequence of zero of more 'O' packets followed, by OK or 'ENN'. IMHO, the only use of Rcmd is to allow user to type some command and see the response, in all other cases query should be defined and used not a command, we have raw queries just for this purpose. > > Andrew > Thanks, Aleksey