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

[Kevin Buettner <kevinb at cygnus dot com>]

On Nov 21, 10:39am, 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.
> 
> I'm looking for direction for fixing this.

It's not pretty, but for IA-64, in config/ia64/tm-ia64.h, I have...

    #if !defined(GDBSERVER)

    #define GDB_MULTI_ARCH 1

    #else /* defines needed for GDBSERVER */
    ...
    #endif

But I'm not necessarily suggesting that this convention be widely
adopted.

The other thing that occurs to me is that defines (or enums) for
things like register numbers ought to be placed in an architecture
specific header file that would *only* be shared between the files
which require it.  I.e, it'd be shared by the ARCH-*tdep.c files
and the ARCH-*nat.c files.  It seems to me that the relevant portions
of gdbserver/low-*.c could suck this file in too.   This wouldn't
address your concern about things like the use of REGISTER_BYTES
in gdbserver/server.[hc] though.