From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9556 invoked by alias); 12 Sep 2005 13:49:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9129 invoked by uid 22791); 12 Sep 2005 13:49:33 -0000 Received: from qnxmail.qnx.com (HELO nimbus.ott.qnx.com) (209.226.137.76) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 12 Sep 2005 13:49:33 +0000 Received: from [10.42.102.101] (10.42.102.101 [10.42.102.101]) by nimbus.ott.qnx.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id R7M0AZBM; Mon, 12 Sep 2005 09:49:31 -0400 Message-ID: <4325880D.40206@qnx.com> Date: Mon, 12 Sep 2005 13:49:00 -0000 From: Kris Warkentin User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb-patches@sources.redhat.com Subject: Re: [patch] Add QNX remote protocol headers. References: <20050912133314.GA28133@nevyn.them.org> In-Reply-To: <20050912133314.GA28133@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00087.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Sep 12, 2005 at 09:11:35AM -0400, Kris Warkentin wrote: > > Well, I don't know about "can't". We support debugging of i386, sh, > > mips, arm and powerpc from Windows, Linux, Solaris and self-hosted > > Neutrino and have for many years using this code. I definitely agree > > with you that the gdb remote protocol is far more portable and that > > passing structures around isn't the safest way to do things. This is, > > however, the way pdebug has always been defined and provided > everyone is > > using gcc, everything works fine. > > > > Basically, I'm acknowledging the limitations of this code and hoping > > that, with certain changes and cleanup, you might consider accepting it > > anyway. Several points: 1) It's a tried and tested solution that has > > been in the field supported by us for more than half a decade. 2) It > > doesn't actually have anything to do with any other gdb mechanisms. > > Completely self contained. If we broke anything, it would only be our > > own stuff. 3) In order to make it completely portable, I'd most likely > > have to avoid passing structures completely and totally re-write the > > entire protocol and server. > > That's all well and good, but you've missed my point. I'm not > complaining about you passing structures around. I'm complaining about > you using structures on the host side to unpack them. > > Here's how it goes: you are contributing support for a new remote > target to GDB. That means you get to pick the target. So you can pick > 32-bit targets with standard packing (well, depending on the content of > the structure, the ARM padding rules may bite you; I'll assume from > your description that this isn't a problem). > > But that new code has no inherent _host_ dependency. It's not > acceptable to take it and say "here's some non-portable code that will > only work on x86, sparc, and neutrino". I can guarantee you that, if > it's in FSF GDB, someone is eventually going to try upgrading to x86_64 > and notice when the pieces all fall apart. > > Passing structures is one thing. Decoding them by dumping binary blobs > into host-side structures is an entirely different thing. But wait! > Fortunately you're working in a debugger with lots of infrastructure > for cross-debugging environments! It'll be a little bulkier, but > there's nothing unsolvable about it. > I think I might be seeing your point. Rather than reading/writing a structure with, say, memcpy, we go through it one field at a time and extract/insert the data based on size and offset? That doesn't sound completely horrible. Is there a good example in the code of an elegant way to do that? I can think of many ways but might there be a 'gdb approved' mechanism? > > >And whatever this does: > > > > > >> #ifdef __QNX__ > > >> __BEGIN_DECLS > > >> #include <_pack64.h> > > >> #endif > > > > > >is similarly not OK. If it's intended to work cross, then it should > > >work from everywhere, not just from x86 and QNX. > > > > > > > That's easy enough to fix. > > > > >I think I need a mile-high explanation of what you're trying to do, > > >first. By the way, is pdebug publically documented? > > > > > > > I hope I've more or less explained it above. I want to submit a > > self-contained patch for our remote protocol that, while not the most > > portable of solutions, will not interfere with anything else. As > far as > > I don't speak for everyone here, but I'm really not interested in > adding non-portable target code to GDB. Non-portable native code, > sure... > > > documentation goes, the descriptions within the headers and source > files > > are just about it. Gdb blocks on the remote which eventually sends > back > > a reply stating the type of event that occurred after which gdb gathers > > whichever information it needs and issues commands back to the target. > > There's a separate channel for I/O. Fairly simple all told. > > Trust me, nothing is ever simple about this sort of thing. I was > hoping there was a manual, but if you don't have one either, we can > make to with what we've got. > > The reason I'm so interested, both in documentation and in portability, > is that you've got a working remote protocol with channels. There's a > lot of incentive to leverage that for other targets. > I see. Well, I suppose I could also talk to my management about releasing the source code for the pdebug server as well. It's actually fairly clean and modular. Having both a host and target implementation of the protocol would probably clarify things. I don't know if they're interested in doing that but we've open-sourced a lot of Eclipse stuff so I imagine there is a precedent. > [I didn't spend much time looking at the attachment. Overall nothing > jumped out at me except the binary blobs on the wire issue.] > Alright. I thought you just didn't like structures being passed at all. If all I need to do is come up with pack/unpack methods, it might not be too bad. cheers, Kris