Re: [5.1/mi] Enable MI interface

[Andrew Cagney <ac131313@cygnus.com>]

Eli Zaretskii wrote:

> So, at the very least, I should review the code in gdb/mi and see that
> it compiles and doesn't do anything that shouldn't be done on
> DOS/Windows.

Yes.  It should compile.

The question, does MI make sense under DJGPP should probably also be
considered.  The current convention is to include everything.  It isn't
for us to decide what someone should or shouldn't use.

> Which reminds me: is there any reasonable way to prevent GDB from
> linking in all those *read.c modules DJGPP users will never need?
> I've never understood why do we have to pull into GDB things like
> mipsread, os9kread, mdebugread, and others, which will never be used.
> (Note that this setup predates multi-arch, so there's got to be some
> reason which doesn't involve multi-arch.)  If I don't link those in, I
> might save a significant part of memory footprint, and prevent the
> line number overflow while at that.

At present no. Because the same GDB can be used to debug both native and
remote targets, support for all possible debuging formats is always
included.  Yes, some of them don't make much sense.

The same issue arises with the simulator targets.  Native GDB's include
simulators even though some people think they are excess baggage.

I think a good time to review these conventions is going to be when
--with-targets=..,.. starts working.  At that point, GDB would be able
to contain everything - gaining more than just a few kilos :-)  It would
probably make sense to only include the debug formats applicable to the
selected group of targets.

	Andrew