Config gdbserver?; Was: [PATCH]: fix typos in gdbserver/low-nbsd.c

[Andrew Cagney <ac131313 at cygnus dot com>]

"J.T. Conklin" wrote:
> 
> I checked in the enclosed patch.  A typo was introduced, perhaps when
> I added powerpc support.
> 
> Maybe we should build gdbserver for all targets where it's configured?

Per

http://sources.redhat.com/ml/gdb-patches/2000-11/msg00113.html

	Andrew

I think there are several cases where gdbserver could be configured:

        --build=X --host=X --target=X
                For X using procfs/ptrace
                Native debugger

        --build=X --host=X --target=Y
                For Y using libsim.a
                Cross debugger

        --build=X --host=Y --target=Y
                For Y using procfs/ptrace
                Canadian cross of native debugger

        --build=X --host=Y --target=Z
                For Z using libsim.a
                Canadian cross of cross debugger

I don't think that the configury should be trying to do things like:

        --build=X --host=X --target=Y
                For Y using procfs/ptrace
                Some people call this host-X-host

A host=X/target=Y procfs/ptrace gdbserver couldn't do anything useful
(well I guess you could NFS mount Y's /proc :-).  A host=Y/target=Y
procfs/ptrace gdbserver is counter-intuitive, it is better handled by
the user explicitly configuring/building a canadian-cross.

I should note that in a number of the above cases
(build=X/host=Y/target=Y and build=X/host=Y/target=Z) there is the 
potential for building both a procfs/ptrace and libsim gdbserver
(example would be ppc-linux).

So I guess the two things to do are:

        o       reach consensus on which of the
                above are useful

        o       fix the configury to match

I should also mention that gdbserver is heading for a period when it is
going to struggle to survive - multi-arch makes it difficult to build a
traditional gdbserver.

Scott Bambrough wrote:
> [...]
> I should be able to add gdbserver to configdirs in configure.tgt, and have
> it built automatically.  This used to work AFAIK.  Somewhere along the line,
> it got broken.  Don't know how, or when, and I really don't care.  The
> configdirs macro from configure.tgt is never used to configure any
> subdirectories AFAICT.  I think this is wrong; it prevents gdbserver from
> being built for any target that adds it to configdirs, it prevents the
> rdi-share directory from being configured automatically for embedded arm
> targets and the nlm directory from being configured for any netware targets.
> IMHO if building gdbserver automatically is not desired for a particular
> target, then the appropriate thing to do is to remove it from configdirs in
> configure.tgt.

I don't think that gdb/gdbserver should be configured unless the target
/ native files explicitly enable it.  This is because, at present, it
isn't enabled and this will have the likely effect of breaking random
target builds :-(

> 
> There is a warning in the README in the gdbserver subdirectory stating that
> it currently doesn't build in a cross-compilation environment.  I don't
> think it makes sense to build other than with host=target.  It has to run on
> the same environment it was built for.  Thus enabling the statement that
> removes gdbserver from configdirs if host != target is a valid thing to do.
> This statement was removed to allow gdbserver to support simulators
> (ChangeLog-97).  Is this currently possible?  If so it needs to be
> considered.
> 
> This issue has been around since July, and needs to be dealt with.  I think
> there is good reason for this change, and I haven't seen any compelling
> arguments why it shouldn't be made.  I've included pointers to my earlier
> RFC and my responses to questions about the patch included there.
> 
> http://sources.redhat.com/ml/gdb-patches/2000-07/msg00375.html
> http://sources.redhat.com/ml/gdb-patches/2000-08/msg00007.html
> http://sources.redhat.com/ml/gdb-patches/2000-08/msg00009.html
> 
enjoy,

        Andrew