Re: [patch] Add QNX remote protocol headers.

[Kris Warkentin <kewarken@qnx.com>]

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