Re: [PATCH]: some gdbserver changes for NetBSD/powerpc

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> >> Does anyone have an example of a multi-arched gdbserver?  For gnu/linux
> >> ppc perhaps?
> 
> Andrew> I don't know that trying to multi-arch gdbserver is useful.
> Andrew> The gdb server is normally built to run on a specific host so
> Andrew> supporting other hosts is kind of wierd.  The only situtation
> Andrew> where I can see it being useful is for a platform that
> Andrew> provides multiple kernel interfaces (NetBSD has Linux compat
> Andrew> mode; Solaris SPARC 32/64) and there I'm not sure of the
> Andrew> tradeoffs.  Simply building two gdbserver binaries would be
> Andrew> easier.
> 
> I'm not really trying to build a gdbserver that can handle multiple
> architectures/targets, but rather fix the netbsd/ppc gdbserver that
> got broken when the gdb ppc target was multi-arched.  In this case,
> REGISTER_BYTES and MAX_REGISTER_RAW_SIZE which used to be defined as
> constants, are now gdbarch functions.  This causes compile time
> failures since these macros are used to size arrays.

Yes.

> I'm looking for direction for fixing this.

(I'm going to fly a kite ....)

The macro's REGISTER_BYTES and MAX_REGISTER_RAW_SIZE currently define
the ``G'' packet.  They shouldn't.  This bug dates back to roughly '85. 
Instead:

	o	something outside of GDB should
		specify the structure of the G
		packet.

	o	gdb/gdbserver should use that
		to construct/dconstruct the G packet.

		The construction code can be hardwired.

	o	remote.c should use it to construct
		and deconstruct a G packet.

		For remote.c, the G packet spec
		needs to be run-time configurable
		so that it can be adjusted independant
		of changing the architecture.

By outside of GDB I mean something that isn't directly compiled in. 
gdbserver may take it and use it to generate code however remote.c would
need the G packet definitiion in a text form so that it could be changed
at run time.

If we can figure out the portable spec then I'm happy to change remote.c
so that it uses it (I need to do this if mips is ever going to be fully
multi-arched :-).

This sets out the requirements.  Next is the solution.  Any thoughts?

	Andrew