This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gdbserver, remote serial protocol and endian issues

> 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 :-(



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]