RE: gdb-h8-stub

RE: gdb-h8-stub

[Andrew Volkov]

Hi Alexei,

Which target is set, when you are run gdb session?
(Be careful: auto=h8300)

Andrey


>-----Original Message-----
>From: Alexei Minayev [mailto:aminayev@yahoo.com]
>Sent: Saturday, July 20, 2002 8:25 PM
>To: Daniel Jacobowitz
>Cc: gdb@sources.redhat.com
>Subject: Re: gdb-h8-stub
>
>
>Hi Daniel,
>
>--- Daniel Jacobowitz <drow@mvista.com> wrote:
>> You have TARGET_ADDR_BIT set too small for your port.  You 
>are probably
>> confusing TARGET_PTR_BIT (the number of bits in a pointer, which can
>> have some separate space marker not included in this count) and
>> TARGET_ADDR_BIT (the number of bits to correctly identify an address
>> when dealing with the OS or stub).
>
>THERE, GOT IT!
>My TARGET_ADDR_BIT is defined as TARGET_INT_BIT, which is 16 
>bit, and my
>target uses 32 bit address space.
>Fixed that problem... that was the help I needed, since I 
>really didn't even
>know where to dig.
>
>THANKS A LOT!
>
>Regards -- Alexei
>> 
>> -- 
>> Daniel Jacobowitz                           Carnegie Mellon 
>University
>> MontaVista Software                         Debian GNU/Linux 
>Developer
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Health - Feel better, live better
>http://health.yahoo.com
>

gdb-h8-stub

[Alexei Minayev]

Dear GDb knights,

I'm confused. My gdb stub does not support binary downloads, but the gdb acts
like it does.
It starts downloading the program as usual:
(gdb) set remotedebug 1
(gdb) load
Loading section .text, size 0x160 lma 0x200000
Sending packet: $X200000,0:#10...Ack
Packet received:
binary downloading NOT suppported by target

note here, the program starts at 0x200000, the gdb sends an 'X' packet with
that address, but receives nothing back. It concludes there, that since the
responce to 'X' is empty, binary download is not supported by target.


But then, it sends a bunch of 'M' commands, which have addresses relative to
the 0x200000 one. But the 0x200000 was sent to target with 'X', and the 'X'
failed...

Sending packet:
$M0,28:01006df60ff67a370000001401006fe0fffc01006fe1fff81aa201006fe2fff41aa28a0201006fe2#74...Ack
Packet received: OK
Sending packet:
$M28,28:fff01aa28a0501006fe2ffec01006f62fff401006f63fff00ab201006fe2ffec1a8088015e2000e4#54...Ack

The question is, am I supposed to support the 'X' command anyway, and
maintain a global "base" memory pointer, which would be set by the 'X'
command? Just curious...


Thanks
Regards -- Alexei

__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

Re: gdb-h8-stub

[Peter Barada]

>I'm confused. My gdb stub does not support binary downloads, but the gdb acts
>like it does.
>It starts downloading the program as usual:
>(gdb) set remotedebug 1
>(gdb) load
>Loading section .text, size 0x160 lma 0x200000
>Sending packet: $X200000,0:#10...Ack
>Packet received:
>binary downloading NOT suppported by target
>
>note here, the program starts at 0x200000, the gdb sends an 'X' packet with
>that address, but receives nothing back. It concludes there, that since the
>responce to 'X' is empty, binary download is not supported by target.
>
>But then, it sends a bunch of 'M' commands, which have addresses relative to
>the 0x200000 one. But the 0x200000 was sent to target with 'X', and the 'X'
>failed...

You're right about gdb infering that the stub doesn't support 'X' by
the empty response packet.  An empty packet is the response the stub
sends back to the host for any command that it doesn't understand.
Once gdb figures out that 'X' (write binary to memory) isn't supported
by the stub(due to the empy packet), it falls back to trying 'M'
(write hex to memory) and finds that it works(since all stubs are
required to support 'M').  The 'X' command is an extension so 'load'
runs about twice as fast.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: gdb-h8-stub

[Daniel Jacobowitz]

On Thu, Jul 18, 2002 at 10:26:30AM -0400, Peter Barada wrote:
> 
> >I'm confused. My gdb stub does not support binary downloads, but the gdb acts
> >like it does.
> >It starts downloading the program as usual:
> >(gdb) set remotedebug 1
> >(gdb) load
> >Loading section .text, size 0x160 lma 0x200000
> >Sending packet: $X200000,0:#10...Ack
> >Packet received:
> >binary downloading NOT suppported by target
> >
> >note here, the program starts at 0x200000, the gdb sends an 'X' packet with
> >that address, but receives nothing back. It concludes there, that since the
> >responce to 'X' is empty, binary download is not supported by target.
> >
> >But then, it sends a bunch of 'M' commands, which have addresses relative to
> >the 0x200000 one. But the 0x200000 was sent to target with 'X', and the 'X'
> >failed...
> 
> You're right about gdb infering that the stub doesn't support 'X' by
> the empty response packet.  An empty packet is the response the stub
> sends back to the host for any command that it doesn't understand.
> Once gdb figures out that 'X' (write binary to memory) isn't supported
> by the stub(due to the empy packet), it falls back to trying 'M'
> (write hex to memory) and finds that it works(since all stubs are
> required to support 'M').  The 'X' command is an extension so 'load'
> runs about twice as fast.

Right.  The corollary is that M and X should be using the same address. 
This works for most targets; you'll need to figure out why it doesn't
work for yours.  It may be a VMA/LMA thing...

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb-h8-stub

[Alexei Minayev]

Hi Daniel,

thanks for clarification.
My question is though, after sending an absolute start address with the 'X'
command, and getting rejected, the gdb doesn't replicate it with 'M' command.
The 'M' command has only relative addresses...

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?

Thanks a lot!
Regards -- Alexei


--- Daniel Jacobowitz <drow@mvista.com> wrote:
> On Thu, Jul 18, 2002 at 10:26:30AM -0400, Peter Barada wrote:
> > 
[skipped]
> > You're right about gdb infering that the stub doesn't support 'X' by
> > the empty response packet.  An empty packet is the response the stub
> > sends back to the host for any command that it doesn't understand.
> > Once gdb figures out that 'X' (write binary to memory) isn't supported
> > by the stub(due to the empy packet), it falls back to trying 'M'
> > (write hex to memory) and finds that it works(since all stubs are
> > required to support 'M').  The 'X' command is an extension so 'load'
> > runs about twice as fast.
> 
> Right.  The corollary is that M and X should be using the same address. 
> This works for most targets; you'll need to figure out why it doesn't
> work for yours.  It may be a VMA/LMA thing...
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer


__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com

Re: gdb-h8-stub

[Daniel Jacobowitz]

On Thu, Jul 18, 2002 at 11:25:50AM -0700, Alexei Minayev wrote:
> Hi Daniel,
> 
> thanks for clarification.
> My question is though, after sending an absolute start address with the 'X'
> command, and getting rejected, the gdb doesn't replicate it with 'M' command.
> The 'M' command has only relative addresses...
> 
> 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.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb-h8-stub

[Alexei Minayev]

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

Re: gdb-h8-stub

[Daniel Jacobowitz]

On Thu, Jul 18, 2002 at 11:00:19PM -0700, Alexei Minayev wrote:
> 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?

The test for the X packet is missing something that is present in
normal use:

  memaddr = remote_address_masked (memaddr);
  p += hexnumstr (p, (ULONGEST) memaddr);
  *p++ = ',';


You have TARGET_ADDR_BIT set too small for your port.  You are probably
confusing TARGET_PTR_BIT (the number of bits in a pointer, which can
have some separate space marker not included in this count) and
TARGET_ADDR_BIT (the number of bits to correctly identify an address
when dealing with the OS or stub).

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: gdb-h8-stub

[Alexei Minayev]

Hi Daniel,

--- Daniel Jacobowitz <drow@mvista.com> wrote:
> You have TARGET_ADDR_BIT set too small for your port.  You are probably
> confusing TARGET_PTR_BIT (the number of bits in a pointer, which can
> have some separate space marker not included in this count) and
> TARGET_ADDR_BIT (the number of bits to correctly identify an address
> when dealing with the OS or stub).

THERE, GOT IT!
My TARGET_ADDR_BIT is defined as TARGET_INT_BIT, which is 16 bit, and my
target uses 32 bit address space.
Fixed that problem... that was the help I needed, since I really didn't even
know where to dig.

THANKS A LOT!

Regards -- Alexei
> 
> -- 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer


__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

Re: gdb-h8-stub

[Peter Barada]

>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.

That is not the intended effect.  The 'X' and 'M' take *absolute*
addresses(see section .  Perhaps you need to debug gdb to see why its trying to
tell the stub to use "X0," (yes, using gdb to debug gdb can get pretty weird).
You'll probably want to put a breakpoint in remote_write_bytes for
this...

See:
http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#IDX1167

for a complete description of the remote protocol.

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)