Re: What's with all the Cisco stuff?

[Stan Shebs <shebs@cygnus.com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 12 Aug 1999 14:51:16 -0700

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
   jtc>  At the very least, shouldn't the cisco specific code be explicitly 
   jtc>  enabled with --enable-cisco-cruft or some such configure option?

   Stan> I did consider this when evaluating Cisco's support bits, and rejected
   Stan> any changes that would have required a special enable flag.  If the
   Stan> presence of this code is making it difficult or impossible for you to
   Stan> use GDB, then I can see adding it, but so far I haven't heard of any
   Stan> usage problems.

   But unlike the remote and monitor backends you mentioned in your
   message, the KOD and mutant remote protocol are bound into every GDB
   configuration, both native and embedded.  At the very best, these are
   only valid for certain embedded toolchains for a single organization.
   What value do these provide that justifies binding them in?

Many of the target backends are nonportable in some way, and can only
be part of certain configurations, so you couldn't include them even
if you wanted to.  I lied about dstread.o, it's actually only linked
into one config, but certainly the Mips- and Alpha-only mdebugread.c
is always included, as is the NLM symbol reader, the Scheme parser,
the Modula-2 parser, not to mention smaller bits of code in various
files.  These are all things that add little or no value to most
users, and yet they're present in every configuration.

That's why I claim that the GDB philosophy is to build in every source
file, unless it's known to have a harmful effect.  I think it's the
right philosophy, because a) the debugger ought to be able to deal
with anything thrown at it, instead of saying "please reconfigure and
rebuild with module X included", and b) I don't see how one could come
up with a fair decision process that included some files and not
others.  What if somebody decided "only support for free OSes may be
compiled in, all others must be configured in explicitly"?  Being
inclusive is simpler to manage and simpler for users.

If nobody but me subscribes to this philosophy, then maybe it should
be changed.  But I think that's the real slippery slope, and would
result in users never being quite sure their versions of GDB could do.

Alternatively, modules could be made dynamically loadable, and I think
that is the right long-term direction; everything still works the same
from the user point of view, and simplifies the base debugger.
Indeed, Fernando tangled with this for kod, the results indicating
that getting dynamic loading right everywhere is a nontrivial task.

								Stan