This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb-h8-stub
- From: Alexei Minayev <aminayev at yahoo dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 18 Jul 2002 23:00:19 -0700 (PDT)
- Subject: Re: gdb-h8-stub
Hi Daniel,
thanks for an interesting discussion.
--- Daniel Jacobowitz <drow@mvista.com> wrote:
> On Thu, Jul 18, 2002 at 11:25:50AM -0700, Alexei Minayev wrote:
> > X200000
> > M0,15:... ; (this would actually mean 0x200000 to 0x200015)
> > M15,15:...
> > M30,15:...
> > ...
> >
> > So according to this, the stub *must* read the address from the X command
and
> > store it for future memory operations, even if it doesn't support binary
> > downloads.
> > In your opinion, is that what gdb means?
>
> No, what I'm trying to say is that that's the wrong behavior for the
> client. You'll need to figure out why GDB is doing this.
>
it might have been the wrong behavior for the client... but it's a very
standard client code, working in many stubs.
The stub code, in particular, when parsing an 'M' command, is looking for an
*absolute* address. But the gdb sends relative addresses to him.
I mean, what could the client possibly say wrong, that gdb chooses a totally
different way of communication?
I went ahead and implemented binary downloading.
Still:
X200000,0...Ack
X0,4e...Ack (I'd expect X200000,4e here)
Packet received: OK
X4e,4e...Ack (expected: X20004e,4e)
Packet received: OK
and so on.
Address is *relative* to what comes in the first packet. E.g. the second
packet gdb sends is "X0", which means "0 bytes +0x200000 base", and the base
value was in the first packet.
Am I forgetting some option or variable?
Thanks
> --
> Daniel Jacobowitz Carnegie Mellon University
> MontaVista Software Debian GNU/Linux Developer
Regards -- Alexei
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com