Mail Archives: djgpp-workers/1999/11/04/14:29:32
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.
- Raw text -