disable gdbserver for cross builds
Andrew Cagney
ac131313@cygnus.com
Wed Nov 8 23:25:00 GMT 2000
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 expalicitly 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
More information about the Gdb-patches
mailing list