From: "Paul Bartlett" <paul.bartlett@st.com>
To: <dmj+@andrew.cmu.edu>
Cc: <gdb@sources.redhat.com>
Subject: Re: gdbserver, remote serial protocol and endian issues
Date: Mon, 08 Apr 2002 09:01:00 -0000 [thread overview]
Message-ID: <00fd01c1df16$685bdd50$300e81a4@bri.st.com> (raw)
In-Reply-To: <20020408114455.A26658@nevyn.them.org>
>
> As soon as you try looking through stack
> frames, you realize that keeping registers
> in target byte order is a lot simpler for
> the rest of GDB.
Yes, I can see that though if you pick up,
say, a 32 bit quantity off the stack into
a machine reg, then the endianness issue is
handled for you by the bus interface unit.
It's only when copying anonymous bytestreams
that you have to explicitly handle endianness.
>
> That's a property of the board, right? It
> expects this shift register to be in its own
> endianness... or is something else going on?
>
No it's a property of the H-UDI port, the debug
port built into the chip itself. We can boot
the target through this without having any
external memory at all (can't do much with it
though ;-))
>
> Nice job, although I'm not sure gdbserver is
> the best base for it; like I said, it's generally
> Unix-based. However, with the other organizational
> cleanup I've been adding to it lately, I think
> there's a clean place to integrate this sort of
> thing now.
>
We (SuperH Inc.) have embraced open-source with
gusto. In a matter of a few weeks we had compiler
with nice gui in place from an almost standing
start. gdbserver seemed to be the closest model
to our older proprietary toolchains and provided
an environment that existing users are reasonably
familiar with.
> I don't suppose you're thinking of contributing it?
> The POSIX I/O stuff especially would be nice to
> have in gdbserver.
We're in the process of trying to arrange this. Part
of the problem is that Hitachi, who originally designed
the chips is nervous about releasing too much detail
about the debug port. It's a very powerful way to get
into a system through the back door.
Although they've assigned the core IP to us, there
were a few strings attached.
If we open-source the adaptor code, then this will
implicitly release much of the information that
Hitachi are trying to keep under their hats.
It's frustrating :-(
Best,
Paul
next prev parent reply other threads:[~2002-04-08 16:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-08 3:48 Paul Bartlett
2002-04-08 7:45 ` Daniel Jacobowitz
[not found] ` <00d501c1df12$ab1bdd60$300e81a4@bri.st.com>
2002-04-08 8:44 ` Daniel Jacobowitz
2002-04-08 9:01 ` Paul Bartlett [this message]
2002-04-08 11:14 ` Andrew Cagney
2002-04-08 19:48 ` Andrew Cagney
2002-04-10 2:50 FW: " Paul Bartlett
2002-04-10 3:05 ` Paul Bartlett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00fd01c1df16$685bdd50$300e81a4@bri.st.com' \
--to=paul.bartlett@st.com \
--cc=dmj+@andrew.cmu.edu \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox