Re: [rfa] gdbserver overhaul

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Oct 17, 2001 at 12:08:59AM -0400, Andrew Cagney wrote:
> >I'd like to commit the attached.  It's just the first stage in what will
> >probably change a few more times; among other highlights it removes the
> >gdbserver dependency on "defs.h" (we still use a few other GDB headers, 
> >like
> >terminal.h, but those will be easy to deal with down the lines).  We lose
> >the xm-/tm-/nm- files at the same time, so to know what the target 
> >registers
> >are we have to hard-code them.  This also makes us independent (at last) of
> >the GDB register cache layout.  GDB does not yet have a corresponding
> >independence, but now that the protocols are clearly and compactly 
> >described
> >in gdbserver, that too can come soon.
> 
> 
> Dan, if I'm reading this right there are two changes involved.
> 
> Break low-linux.c down into separate files.
> Introduce and use regdef.[hc].
> 
> With regard to breaking down low-linux.c into CPU specific files.  The 
> actual process doesn't worry me (probably a good move).  You would need 
> to do the other platforms at the same time so that gdbserver doesn't end 
> up with two different schema.  My one concern is the file name choice, I 
> would definitly use linux in preference to lnx since the former is used 
> every else in GDB.  I'd also consider adding a suffix/prefix - there is 
> low-* already.  (Unless you're proposing we change the other files to lnx.)

As far as that goes, I can't reliably break the others apart.  It's
very tricky to do without a platform to compile them on.  That changes
interfaces only within low-linux itself, though, so I'm not terribly
concerned.  And, as I've mentioned, most of those other targets are
really just myths nowadays.

I used lnx-, because they needed to be 8.3 unique - isn't that
preferred to an entry in fnmatch.* (?)?  They were originally
low-linux-*.c instead, which was much more logical to me.  I'll go back
to that if the 8.3 conflicts are not a concern.

> Regarding regdef:
> 
> >+struct reg arm_regs[] = {
> >+  R4("r0"),  R4("r1"),  R4("r2"),  R4("r3"),
> >+  R4("r4"),  R4("r5"),  R4("r6"),  R4("r7"),
> >+  R4("r8"),  R4("r9"),  R4("r10"), R4("r11"),
> >+  R4("r12"), R4("sp"),  R4("lr"),  R4("pc"),
> >+  R12("f0"), R12("f1"), R12("f2"), R12("f3"),
> >+  R12("f4"), R12("f5"), R12("f6"), R12("f7"),
> >+  R4("fps"), R4("cpsr"),
> 
> Have you thought about using something like a colon delimited file:
> 
> 4:r0
> 8:r1
> 
> to generate these?  A definition for a textual form will be needed 
> eventually.  While crude it would allow the sharing of this information 
> between GDB and gdbserver.

I've thought about it.  The text file would also need to specify
registers to be sent in a resume packet, or those could be moved to the
low* files without too much pain (although they're really per-cpu
rather than per-target, which is why I put them where they are).

This bears some more consideration, but if the patch is otherwise OK I
would like to postpone it a little bit.  I'd like to factor out code
and information useful for communicating between gdb and gdbserver into
its own area; I'd also like to factor out code for control of native
targets (ideally extending as far as the linux threads control
package!) into something that could be shared.  I've got a couple of
developing ideas for how to do this, but I'd prefer not to mix it with
this much-needed (IMHO) breath of life.

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