Re: [patch] Add QNX remote protocol headers.

Kris Warkentin
2005-09-12T13:49:47Z

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