From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ronald F. Guilmette" To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file Date: Mon, 30 Apr 2001 17:36:00 -0000 Message-id: <20010501003601.8470.qmail@sourceware.cygnus.com> X-SW-Source: 2001-04/msg00762.html List-Id: The following reply was made to PR c/2678; it has been noted by GNATS. From: "Ronald F. Guilmette" To: Phil Edwards Cc: "Joseph S. Myers" , 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 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.