Re: c/2678: gcc/g++ should stick compilation options into the .o file

["Ronald F. Guilmette" <rfg@monkeys.com>]

The following reply was made to PR c/2678; it has been noted by GNATS.

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: "Joseph S. Myers" <jsm28@cam.ac.uk>, gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file 
Date: Mon, 30 Apr 2001 17:29:44 -0700

 In message <20010430184754.A1637@disaster.jaj.com>, you wrote:
 
 >On Mon, Apr 30, 2001 at 10:21:12AM -0700, Ronald F. Guilmette wrote:
 >> >But does "strip" (without other options) remove these sections?  It
 >> >doesn't (binutils 2.11.90.0.6) remove .comment and .note; for that reason,
 >> >Debian has modified "install -s" to pass --remove-section=.comment
 >> >--remove-section=.note to strip.
 >> 
 >> a)  It's no big deal to also supply --remove-section=.comment on the
 >>     strip command line.
 >
 >Other implementations of strip do not understand this option.  We should
 >not punish them.
 
 If somebody is using gcc, they can bloody well used GNU strip too.  If they
 don't, that's their problem.
 
 Try using gcc output with somebody else's symbolic debugger sometime.  You'll
 see what I mean.
 
 Deep interoperability with Other People's Tools hasn't been on the GNU
 agenda for a long long time.  I argued for it, long and hard, a long time
 ago, but I lost that battle.
 
 >> b)  In practice, nobody will give a damn about the presence or absense of
 >>     this extra information anyway.
 >
 >Yes, they will.  More specifically, /we/ will as we build GCC itself.
 >
 >Right now things like crtbegin.o and libgcc2 and lib<pick-a-language> are
 >all getting this information added to them.  It's not a problem with memory
 >consumption because they aren't allocated.  It is however a correctness
 >problem because the final executable gets about five copies of the options
 >strings (the assembler and linker combine the separate instances of the
 >identically-named sections).
 
 That last (parenthesized) part is true, in a general, total, and complete
 sense, if and only if you are NOT using -s with ld.  Otherwise the linker
 does not ``combine'' but rather _ignores_ certain input sections.
 
 >But the first set of options are those passed when compiling crtbegin,
 >the second set are those passed when compiling some chunk of libgcc2,
 >{etc}...
 
 Yes, you are correct that once you get past mere .o files and start get-
 ting into linking, keeping this data around (e.g. in the linker's output
 file) may perhaps be a less-than-wonderful idea.  (But see below.)
 
 OK.  So now _here_ is a good excuse to come up with a new GNU invention...
 a new ``GNU standardized'' ELF section name.
 
 For lack of a better name, let's call it `.ignore_me'.
 
 All .ignore_me sections would have special semantics (at least to the GNU
 linker) at link time.  Specifically, the special semantics would be that
 the linker just avoids coping them into the final executable (or shared
 library).
 
 Hummm... OK.  Wait a minute.  That would work, but I have a better idea...
 
 Just _label_ each one of these hunks of option information with the
 specific corresponding .c or .C ``primary'' source file name that was
 being compiled when those options were used.  Then the final linked
 file would, in effect contain essentially a complete history, telling
 you how it got built.  Hell!  You could practically write a program
 to automatically reverse-engineer and re-create the original Makefiles
 (or files functionally equivalent to them) just from the final linked
 executable!
 
 Ok, so maybe a use for such a capability won't come up THAT often, but
 hey!  You never know.  I always keep my server logs around for at least
 a full week, just in case.  Why should this info be any different?
 
 It is always good to leave a trail of breadcrumbs, so that you can get
 back the way you came.