From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [5.1/mi] Enable MI interface Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: References: <3AA417E8.4F9A1348@cygnus.com> X-SW-Source: 2001-03/msg00053.html 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 DOS/Windows. > 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).