NPC_REGNUM, multi-arch and gdbserver

[Stan Shebs]

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.

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.

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.

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.

Stan