This is the mail archive of the
mailing list for the GDB project.
Re: nindy protocol
"J.T. Conklin" wrote:
> >>>>> "Stan" == Stan Shebs <firstname.lastname@example.org> writes:
> Stan> I squirreled away a couple copies of CTOOLs when I was at Cygnus, but
> Stan> I don't know if any were old enough to include Nindy sources still;
> Stan> don't remember ever seeing actual Nindy sources.
> Do you still have access to them? I found the CTOOLS 5.0 release
> notes on developer.intel.com --- it looks like Nindy was replaced
> then. If you have an earlier release, it should have the Nindy
Actually, I think 5.0 is the earliest I have too.
> Stan> I could do the research to justify obsoleting Nindy, then you'd
> Stan> be free to whack the dcache functions (remote-bug.c is also an
> Stan> obsoletion possibility BTW).
> Feel free. I'm not going to argue against it. However, if Nindy
> supports arbitrary sized and aligned memory transfers the changes
> necessary to remove dcache_fetch() and dcache_poke() are trivial. If
> we can't determine whether it's safe, and you want to wait more before
> obsoleting the config, I propose that we commit it anyway. If it
> breaks anything and anyone cares, we'll hear about it soon enough.
Fine by me.
> If the MVME187BUG monitor is anything like the m68k, ppc, and coldfire
> versions of BUG, it could be rewritten to use the generic monitor code,
> resulting in a smaller and more robust target. Whether anyone cares to
> do so is another story.
There was at least one m88k workstation alive recently, somebody on this
whose name I forget (sorry) sent in some patches for it last year or so.
But embedded m88k boards these days? Rather unlikely I think.
> If remote-bug.c is obsoleted, it appears that
> most of remote-utils.c (all the gr_* stuff) can too.
Yup, an attractive side benefit. To borrow from S&W, "omit needless code". :-)