This is the mail archive of the
mailing list for the GDB project.
Re: [5.1/mi] Enable MI interface
- To: Andrew Cagney <ac131313 at cygnus dot com>
- Subject: Re: [5.1/mi] Enable MI interface
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- Date: Tue, 6 Mar 2001 10:45:55 +0200 (IST)
- cc: gdb at sources dot redhat dot com
On Mon, 5 Mar 2001, Andrew Cagney wrote:
> > Bother. Can you, or someone else, please describe in a few words what
> > does "enable the MI interface" mean, in practical terms, for a port
> > such as the DJGPP port?
> Nothing (yes, ok famous last words :-).
> At present the gdb/mi directory isn't built. Enabling the MI would mean
> building that directory and linking it into GDB.
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
> For a DJGPP user, this just means that GDB gained a few kilos.
That's actually not so good: the current build already overflows the
COFF limit of 64K lines in the debug info, albeit by a small margin;
adding more code will make things much worse...
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.
> The big change really occured ~2 months ago when ui-out became the
> normal mechanism to use when outputing something.
Well, this already works for me (I'm using a month-old snapshot).