Re: What's with all the Cisco stuff?

[Andrew Cagney <ac131313@cygnus.com>]

"J.T. Conklin" wrote:
> 
> What's the deal with all the Cisco-specific stuff ending up in GDB?

I'll ignore the politics :-)

At a technical level, the ``cisco-stuff'' highlights a limitation of the
current target vector - you can't build up a true target stack.  (To get
a knife out, here I'm not talking about that *(&!@)$(& strata tha
currently exists in GDB :-)

The CISCO code should be implemented as a sequence:

	o	open the target using generic ``remote.c''.

	o	create a new target that passes through most
		requests but every so often interseeds an
		operation with a cisco specific on.

Re-vamping that code, isn't trivial - I looked at it doing some fixes
for the the d10v target.  At the time I backed away.
At present the task sits in my input stack :-(

	Andrew
From tromey@cygnus.com Thu Aug 12 23:15:00 1999
From: Tom Tromey <tromey@cygnus.com>
To: gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Thu, 12 Aug 1999 23:15:00 -0000
Message-id: <87g11ow75w.fsf@cygnus.com>
References: <199908122301.QAA03422@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00160.html
Content-length: 1168

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

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

FWIW, getting this right for most useful host systems is easy: use
`libltdl', which comes with libtool.  I decided not to do this for
kod-cisco.c because I lost interest and time.  If someone wants to
libtoolize kod-cisco.c and add the required code to kod.c (and ltdl to
the build infrastructure) I would be happy to provide pointers and
advice.

It would be nice if different parts of gdb could be dynamically
loaded.  For instance, I'd rather not have support for Modula-2, or
Scheme, or even Java (shock, horror) unless I was debugging an
executable that needed these bits.  (This presumes that the savings
are worth the effort.  I haven't looked to see whether this is so, and
I suspect they are not.)

Tom
From gatliff@haulpak.com Fri Aug 13 06:13:00 1999
From: William Gatliff <gatliff@haulpak.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: What's with all the Cisco stuff?
Date: Fri, 13 Aug 1999 06:13:00 -0000
Message-id: <37B419FD.C9748ABE@haulpak.com>
References: <199908122320.QAA04670@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00161.html
Content-length: 918

Guys:

I'm not sure I understand all the debate on KOD, so I'll stick to the parts
I know...

> I would ecstatic with more interest and input here.  "RTOS support" is
> an area where GDB gets hammered relative to its competition, and
> display of kernel objects is a specific feature that gets comes up
> frequently.

On the embedded side, could RTOS support be made a stub issue, instead of a
gdb issue?  As an embedded developer, I find it much easier to add/modify a
stub than to muck around with the internals of gdb itself.

If there were a standard set of RDP messages that could be used to deliver
OS information from a stub back to gdb, then I would be happy to add stub
support for my own RTOS, whatever that happens to be, using the RTOS's
native calls.

Perhaps this approach could be extended for non-remote debugging, as well?

b.g.

--
William A. Gatliff
Senior Design Engineer
Komatsu Mining Systems