This is the mail archive of the
mailing list for the GDB project.
Re: [patch] Add QNX remote protocol headers.
- From: Daniel Jacobowitz <drow at false dot org>
- To: Kris Warkentin <kewarken at qnx dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 12 Sep 2005 16:36:50 -0400
- Subject: Re: [patch] Add QNX remote protocol headers.
- References: <20050912133314.GA28133@nevyn.them.org> <4325880D.firstname.lastname@example.org>
On Mon, Sep 12, 2005 at 09:52:13AM -0400, Kris Warkentin wrote:
> 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?
Exactly! And I assume that (somewhere I didn't see) you've already got
byteswapping for this; that can happen at the same time.
This is historically a PITA for the siginfo unions, but it's doable.
You could treat these things as target types and use the GDB value
mechanism to access them. It's a bit overkill, but it's also very well
tested. There's an example in build_gdb_vtable_type, in gnu-v3-abi.c.
> >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.
Up to you; this isn't important to me. If I'm going to have to
reconstruct it from the source anyway the server side ought to be
enough :-) We wouldn't want something exactly the same, anyway, I
> >[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.
Right, that's what I meant. The structures, in the layouts you're
using, are "target independent" for the set of targets you support.
So it's no different from any network protocol. I just don't want the
implementation and the specification to get mixed up in GDB.
We've had this problem before. It's no different from the code that
lets me use an opteron system to debug an i386-linux core file.