Fw: gdbserver, remote serial protocol and endian issues

Fw: gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

----- Original Message -----
From: "Paul Bartlett" <paul.bartlett@st.com>
To: <ac131313@cygnus.com>
Sent: Tuesday, April 09, 2002 5:28 PM
Subject: Re: gdbserver, remote serial protocol and endian issues


>
> > I assume you mean something like a memory read at &foo only
> works if
>  > done as a 16 bit operation by the remote target.
>
> Yes. There are certain configuration registers for SH4/SH5
that
> appear
> in the memory map that *must* be written using the appropriate
> access size.
>
> > Proposals for an extension to the protocol that implement
this
> have been
> > posted (search for e-mail from jtc).  The memory attribute
> framework was
> > introduced in preparation for this.
>
> I've spent a good proportion of the day trawling the list
> archives for JT Conklin's stuff.
>
> I noticed that he was a prolific contributor up to about 16
July
> 2001 and then just disappeared completely.
>
> A cursory inspection of remote.c shows that the memory
attribute
> changes have made it down to remote_xfer_memory(). I presume
> that all that needs to be done (for remote targets anyhow) is
to
> come up with suitable changes to the rsp and propagate the
> parameters through.
>
> I see that one of JT's last contributions was a suggested
> syntax.
>
> Does anybody have any opinions on which way to go from here?
>
> Paul
>
>

Re: Fw: gdbserver, remote serial protocol and endian issues

[Andrew Cagney]

Paul,  can you forward the reply I sent you to the list.

Andrew

FW: gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

-----Original Message-----
From: ac131313@cygnus.com [mailto:ac131313@cygnus.com]
Sent: 09 April 2002 18:14
To: paul.bartlett@st.com
Subject: Re: gdbserver, remote serial protocol and endian issues


> 
> I've spent a good proportion of the day trawling the list
> archives for JT Conklin's stuff.
> 
> I noticed that he was a prolific contributor up to about 16 July
> 2001 and then just disappeared completely.

He was overtaken by other commitments.

> A cursory inspection of remote.c shows that the memory attribute
> changes have made it down to remote_xfer_memory(). I presume
> that all that needs to be done (for remote targets anyhow) is to
> come up with suitable changes to the rsp and propagate the
> parameters through.
> 
> I see that one of JT's last contributions was a suggested
> syntax.

> Does anybody have any opinions on which way to go from here?

Proceduraly or technically?

Proceduraly, the first thing to do is get the GDB community to agree on 
the protocol extension.

Technically, the first thing to do would be the same - without that 
agreement you run the (real) risk of implementing a protocol extension 
that isn't accepted into the GDB source tree.

enjoy,
Andrew

Fw: gdbserver, remote serial protocol and endian issues

[Paul Bartlett]

----- Original Message -----
From: "Paul Bartlett" <paul.bartlett@st.com>
To: <drow@mvista.com>
Sent: Monday, April 08, 2002 4:33 PM
Subject: Re: gdbserver, remote serial protocol and endian issues


> Hi Daniel,
>
> > I don't agree.  Target registers are in
> > target-endianness when you read them off
> > the stack; they should be in target endianness
> > in memory.  GDB has 'set endian little' and
> > 'set endian big', and the stub should just pass
> > them along however it gets them.  gdbserver is
> > also meant to run in a native configuration,
> > where compile-time checks can tell you the
> > endianness.
>
> Well, maybe I'm guilty of not considering the
> general case - haven't thought it through yet.
>
> Our application connects to the H-UDI (JTAG)
> port of the SH4 for high speed (~20 MBits/s)
> access through the back door into the chip.
>
> The physical implementation includes a 32 bit
> shift register. What we notice is that if we
> change endianness then we have to endswap the
> 32 bit quantity that appears in the register
> before transferring it to the target machine
> reg. - it never actually gets into memory.
>
> > My first impression is that gdbserver is the
> > wrong tool for the job. Gdbserver is meant as
> > a remote stub for Unix-like systems.  You're
> > not running it on a Unix-like system; you're
> > using it as a proxy, right? Since GDB already
> > has a stub to speak to the hardware monitor
> > on SH4 boards, as far as I'm aware.
> > This sounds like a job for rproxy
> > (http://world.std.com/~qqi) instead.
>
> Maybe we re-invented the wheel, some. Our
> implementation runs on a box equipped with
> cpu/flash/ram and ethernet and jtag interfaces.
> It does implement the remote protocol in much
> the same way that rproxy does, but also adds
> facilities like posix i/o through the debug
> port.
>
> Works well. We've used it for debugging both
> 'bare machine' embedded and rtos based apps.
> (I also brought up a linux kernel with it).
>
> Best,
>
> Paul
>
>