Re: [rfa] gdbserver overhaul

Daniel Jacobowitz
2001-10-16T21:23:00Z

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