Re: NPC_REGNUM, multi-arch and gdbserver

[Andrew Cagney <ac131313 at cygnus dot com>]

Stan Shebs wrote:
> 
> Andrew Cagney wrote:
> >
> > the underlying problem/question is how should gdbserver be built when
> > the upper-level GDB is being built multi-arch?
> >
> > Comments, ideas?
> 
> I've thought about this from time to time...
> 
> So the basic theory of gdbserver is that it's a stub for native
> systems, which means that it consists of a) a target-side remote
> protocol implementation, and b) a blob of native-only code to
> implement the remote protocol packets.  Ideally, the blob of
> native code is the same as is used in full GDB, but in practice
> we replicate and strip down right now.
> 
> The crux of the problem is that the lowest levels of native
> support may still need to know something about the target
> architecture, such as the number and size of registers, even
> though gdbserver doesn't have to care about stack frame layout
> or any other of the higher-level ABI knowledge.
> 
> One possibility would be to have two architecture objects,
> a "higher level" one and a "lower level" one, or, as we've talked
> some about in the past, an "ABI" object that is different from
> a "raw arch" object, and then use the lower-level one in gdbserver.
> This is a bit much to bite off right now perhaps.

Er, yes. Lets first figure out a cannonical list of architecture methods
(high or low) :-).

> Another possibility would be to bolt the whole multi-arch framework
> into gdbserver.  Although gdbserver should be small, it is intended
> to run on host systems, and so it doesn't have the stringent constraints
> of the usual embedded target.

I poked at that (linking gdbserver against libgdb.a) and it pulled in
all of GDB.

At present GDB is very undiciplined (it needs a good marching up and
down in the desert (sp?)) with random and arbitrary references.

> Finally, we could just say that gdbserver doesn't need to share
> anything with main GDB sources, and just kludge everything.  This
> has the virtue of simplicity; we're not doubling the size of our
> source base for the sake of two macros.

I have a feeling this is the most pratical short term solution :-(  It
means that either a separate copy of those needed macros is created, or
GDB be used to dump out the relevant macro's for gdbserver (ulgh).

Things like sparc32/64 would probably need two executables.
	
> Personally, I lean towards having the option of including multi-arch
> in gdbserver, mostly because in the long run I think we should make
> gdb and gdbserver use the same code as much as possible, and native
> support will in general need to access information about the target
> architecture.  Using multi-arch means that gdbserver is more likely
> to "just work" and need less individual maintenance.

For it to ``just work'' I think we first need to get GDB into ship-shape
with respect to the basic gdbarch. Then we can re-arange things so that
there is a separation of the ISA/ABI.  With that, making use of it by
gdbserver may be possible.

Looking down the track, there are two potential common area's between
GDB and GDBSERVER:

	o	the [Gg] packet layout.

		I think this external interface should be
		defined in, say src/include/gdb/???.h.

	o	the mechanism used to read/write
		individual registers

beyond that I'm not sure how much commonality there will really be.

I'll see what tricks I can come up with for gdbarch in the non-
multi-arch case to keep it going.

	Andrew