This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: What's with all the Cisco stuff?


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

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

While the other changes going may be significant, I don't consider
them controversial because they've been on the roadmap and there have
been discussed on the list.  I consider a new command, or even more a
new subsystem, that hasn't had the benefit of open discussion to shape
its development that is integrated without notice a much more
controversial situation.

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

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

The current implementation suffers from an even greater drawback ---
It needs a 'live' system to work.  If the OS may doesn't allow you to
access kernel structures, let's solve that problem, as there may be a
need to access kernel structures in a less processed manner.  If the
representation of kernel objects changes, you're would have to change
the KOD code in the debug agent (stub), which is pretty much the same
as changing code in a gdb script.

If for some reason there is a need for KOD outside of gdb's scripting
ability, it needs to include the experience of a larger pool of
embedded systems users.  

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]