X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Thu, 4 Nov 1999 19:23:53 +0100 (MET) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: djgpp-workers AT delorie DOT com Subject: Re: -g vs -s In-Reply-To: <3821C6EF.E6BACF9B@hmc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk I've been watching this discussion for a while now, but kept my mouth shut. But I think it's now time to tell you why I, for one, think that this idea is a rather bad one. On Thu, 4 Nov 1999, Nate Eldredge wrote: [...] > But in any case, I don't think this is worth it. I've never been a fan > of changing legitimate behavior for the sake of people who won't RTFM, > and this is a fairly well ingrained behavior of GCC-- Exactly. We would make our gcc behave differently (and rather unexpectedly, to all seasoned gcc users) than all gcc versions. Or most other Unix-style command line compilers, for that matter. > unless you specify > otherwise, the link stage just puts all the object files together. For > instance, -g is documented as a compilation option and not a link > option, so our behavior would then not match the GCC manual, leading to > further confusion. This is another strong argument I had intended to inject into this discussion. '-g' is a *compilation* flag, while '-s' is a linking flag. The two have no real link to each other, originally, and I don't think we should introduce one, behind scenes, just to please non-RTFMers. As Nate already pointed out, it wouldn'd really help against the 'huge exe' FAQ, anyway, so it's not worth the hassle. We'ld be reducing the frequency of one FAQ, but create a new one in return: 'Where did my debug info go? I *did* compile with '-g', but it doesn't work!' The only partly sensible implementation of such a behaviour, as I see it, would be for the linker itself to detect that none of the .o files it's been given contains debugging info (excepting the symbols info for exported functions and variables, which will of course always be there). Then, and _only_ then should the linker automatically fall back to '-s' as its default. But then, the gain would be so small as to be unnoticeable, as the exported symbols usually don't take anywhere near as much space in the executable as full debugging information would. It's on the order of a few percent of executable size, IIRC. So there's no point implementing this method, either. As long as any of the .o files were compiled with '-g', an automagic stripped linkage behind the scenes would be a break of concept. The users should not be forced to pass a compilation option to the linking stage, to stop the linker from doing stripping the executable. In short: users who don't bother reading docs somewhat _deserve_ getting overly large executables, as a kind of punishment for disrespect of our trusty manual authors, IMHO. 'Small sins the Lord punishes right away', as a German proverb goes. Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.