Re: What's with all the Cisco stuff?

[Stan Shebs <shebs@cygnus.com>]

   From: jtc@redback.com (J.T. Conklin)
   Date: 10 Aug 1999 21:42:48 -0700

   What's the deal with all the Cisco-specific stuff ending up in GDB?

A fair question.  I apologize for not discussing this on the list
previously; this seemed pretty non-controversial compared to some
of the other changes that are going on...

   We recently saw the introduction of a mutant Cisco variant of the
   remote debug protocol (which doesn't offer any advantages over the
   existing RDP), and the latest snapshot contains some sort of kernel
   object display code for IOS that is bound into every GDB, native or
   embedded.

Actually, the kernel object display mechanism is supposed to be generic
and is thus available for any RTOS that wishes to make use of it.  To
answer an implied question in a different message, you can't do this
with user-defined commands alone, because the OS may not let you
access kernel data structures directly, or the representation may
change from one release to the next.

   I'll argue that code for _any_ company's in-house systems is not
   appropriate to be integrated into GDB.  Unlike support for an embedded
   OS, which benefits a broad developer community; integrating code for a
   closed system benefits only that company, especially as responsibility
   for continued maintenance of whatever oddball way of doing things now
   falls on the shoulders of future GDB maintainers.

   By integrating this code, we have also set up a slipery slope where
   similar code from other companies cannot be rejected out of hand. The
   nature of embedded systems is that companies are going to have unique
   requirements and specialized code that are of use and interest only
   within.  Is all such code going to be welcomed in GDB?  Or only code
   from Cygnus' customer list?

That's a little unfair... In actual fact, over the past five years
I have not rejected any contribution because the system in question
was "in-house".  There are several reasons for this.

First, there is ample precedent.  bfd/cisco-core.c was added by Jim
Kingdon in 1994.  remote-array.c is only useful for Array
Technologies, while remote-st.c, which has been in GDB forever, is for
Tandem phone switches.  sh3-rom.c is an SH target that I don't think
was ever available to the general public, and you yourself recently
noted that the PowerPC bits in gdb/nlm were for a product that never
saw the light of day.

Second, think about the process of accepting or rejecting these kinds
of additions; how is one supposed to be decide whether something is an
"in-house-only" system?  I accept patches for systems that I don't
personally have access to, and indeed with no way of knowing whether
they are available to a broad developer community.  I'm pretty certain
that there are more Cisco IOS hackers in the world than there are
Mitsubishi d10v and d30v hackers put together, and yet nobody seems to
have a problem with architecture-specific code that is not useful to
anyone outside of Mitsubishi.

Third, I don't want to encourage variant versions of GDB.  Divergence
begets more divergence, and results in permanent forks.  Unlike GCC,
sooner or later GDB has to be able to get very grubby with the details
of real systems.  If this can only be done by patching GDB, then that
means the base sources are incomplete.  Ultimately I'd like to see
more modularity for system-specific bits, but we're not there yet, and
I don't want to see users switching to other debuggers because we're
waiting for somebody to write more elegant code.

Fourth, the basic design philosophy for GDB is that it is a bag of
tools for debugging.  All we really require is that each tool be
useful to someone, and that each tool doesn't interfere with any of
the other tools.  Every version of GDB has an Apollo Domain symbol
reader (dstread.c) compiled in, even though it's highly unlikely that
the average embedded programmer will need it.  It just stays out of
the way and unnoticed, but is ready should an Apollo-like set of
symbols ever appear in an object file.  When we talk about making a
universal GDB that includes support for all architectures, that's
another expression of the philosophy - why have different GDB builds
for different target architectures, if they can all play nice
together?  So by that philosophy, it should be acceptable to have
OS-specific bits in GDB builds, whether or not the OS is common or
popular or on sale at Fry's.

Again, I apologize for not discussing this in public earlier.  I've
been operating with the abovementioned philosophy for awhile, but
haven't tried to articulate it clearly until now.  I suspect that as a
result, you and others have probably been self-censoring on patches
that would actually be quite reasonable for GDB.  So yes, I would like
to see any patches that people have been holding back on because they
thought they were too system-specific.

   At the very least, shouldn't the cisco specific code be explicitly 
   enabled with --enable-cisco-cruft or some such configure option?

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

								Stan