From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23039 invoked by alias); 6 Feb 2004 02:49:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23030 invoked from network); 6 Feb 2004 02:49:27 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 6 Feb 2004 02:49:27 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 84F24357B; Thu, 5 Feb 2004 18:49:26 -0800 (PST) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i162nPOi009814; Thu, 5 Feb 2004 18:49:25 -0800 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i162nP8R009810; Thu, 5 Feb 2004 18:49:25 -0800 Date: Fri, 06 Feb 2004 02:49:00 -0000 Message-Id: <200402060249.i162nP8R009810@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: remote protocol support for TARGET_OBJECT_AUXV In-Reply-To: Andrew Cagney's message of Thursday, 5 February 2004 10:54:56 -0500 <40226750.6030603@gnu.org> X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. X-SW-Source: 2004-02/txt/msg00054.txt.bz2 > I think it would be better to specify something that accomodates this > (to my suprise) rapidly expanding interface. > Otherwize, in a month or so, we'll find ourselves discussing the exact > saome problem for "unwind-table", "wcookie", "avr", and "kod". In the gdb-patches thread, I suggested such an idea as well. The details of transmitting offset/length and getting back data/eof is something we should decide once and do the same for all new cases, whether they are technically the same query or not. > I also think that the protocol semantics should reflect this interfaces > semantics (or a superset of it). That seems reasonable to me, hence my prior similar suggestion. However, I also sympathize with the opinion Dan expressed. I will paraphrase that as that the stub's job should be kept simple whenever possible. The stubs are after all, stubs (i.e. small things), and there are many of them, whereas gdb is big and hairy and so extra layers of well-organizedness are good in gdb but sometimes bad for stubs. > (technical nit "+" can't be used. Right! Thanks. It's been a long time since I was in the habit of typing gdb remote protocol by hand, so I'd forgotten what is and isn't encoded how. Your having reminded me, I went and re-read the elisp I used to do that. > -> qPartial::read::, > <- OK -- implicit zero length returned EOF > <- -- must contain the byte @ > <- "" -- packet not recognized > <- Enn - something wrong with the request > > -> qPartial::write::: > <- -- number of bytes actially written > <- "" -- packet not recognized > <- Enn -- something wrong with the request This looks fine to me, basically. But I do think it is worth starting out with the one more wrinkle of EOF reporting along with data return. With this simpler protocol, there are necessarily two request/reply transactions for every time you want to read "all the data", even if there is as little as one byte of it to read. That seems unnecessary and undesireable. (Perhaps I've spent too long doing serial debugging when serial ports were slower than they usually are these days. But all the remote protocol traffic adds up to slow sessions hacking kernels.) This is only worthwhile if the target_read_partial usage conventions are able to express it. But I think that is a change worth making as well. This goes to the issue with target_auxv_read that you cited. If it must make additional target_read_partial requests until one returns zero, then all target implementations necessarily have their analogues of the remote protocol's extra packet here. To wit, the Linux implementation would do open+read+close+open+lseek+read+close instead of just open+read+close. That can obviously be internally optimized to make the worst case be open+pread+pread+close, but that is still one more system call than is really required to answer the whole question the caller of target_read_partial is asking. I think these improvements are worth pursuing without delay. However, I don't see any reason not to go ahead with the protocol you have proposed in the interim, since I can implement that in a few minutes without perturbing anything else. > -> qPartial:? > <- OK -- queries of type are supported > <- "" -- queries of type are not supported What does "supported" here mean exactly? A stub will e.g. support reading but not writing, and a very constrained range of "annex" values. If an OK response to "qPartial:foo?" just means that you have some chance if you try some particular read/write query, is there a particular benefit to that over just trying the first query you wanted and taking the empty reply as "not supported"? > a variation being something like: > qPartial:obj=:op=write[:annex=]:offset=:data= > which makes it more extensible. That is not really any more extensible, I'd say. You can just define new tokens after the first or second : to change the details later. This is just more verbose, unless it's free form as to the order of parameters. Being free form is less desireable because it requires hairy parsing in the stub instead of just matching fixed leading strings for the few particular requests that are actually supported. Thanks, Roland