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

[Phil Edwards <pedwards@disaster.jaj.com>]

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

From: Phil Edwards <pedwards@disaster.jaj.com>
To: "Ronald F. Guilmette" <rfg@monkeys.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 18:47:54 -0400

 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.
 
 
 > 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).
 
 But the first set of options are those passed when compiling crtbegin,
 the second set are those passed when compiling some chunk of libgcc2,
 there are many copies from various libstdc++ files in there if you happen
 to use C++, and only /one/ of those copies contains the options that the
 user actually passed when compiling the "real" source file.  Which one?
 No way of knowing without doing a crapload of grep's.  But all the sets
 are slightly different (e.g., we pass -D optiosn when building ourselves
 that a user wouldn't).
 
 I haven't tried a full bootstrap with my half-baked changes in yet, but
 would expect it to fail because all the .o's would probably differ.
 
 Anyhow, adding a disabling flag took about four lines of code.  I still
 plan to make this on by default (otherwise it'll never get used, and the
 presence of the information will be highly unpredictable).
 
 
 Phil
 
 -- 
 pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
 devphil at several other less interesting addresses in various dot domains
 The gods do not protect fools.  Fools are protected by more capable fools.