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