public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2002-11-05 7:46 Wolfgang Bangerth
0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Bangerth @ 2002-11-05 7:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: pedwards@disaster.jaj.com, <rfg@monkeys.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o
file
Date: Tue, 5 Nov 2002 09:41:10 -0600 (CST)
Phil, Ronald,
you two have been writing a _lot_ of text about this report, but from
reading two sentences every second page, I was not clear about whether
anything has been implemented at all. What's the status of this report?
I'm just trying to sift through the old reports and try to close that are
no longer valid. 1800+ non-closed reports is simply getting too many...
Thanks
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2002-11-05 9:16 Wolfgang Bangerth
0 siblings, 0 replies; 17+ messages in thread
From: Wolfgang Bangerth @ 2002-11-05 9:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Phil Edwards <phil@jaj.com>
Cc: rfg@monkeys.com, <gcc-gnats@gcc.gnu.org>
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o
file
Date: Tue, 5 Nov 2002 11:09:46 -0600 (CST)
> [ note that the pedwards address is now invalid ]
Yeah, I noticed that.
> > you two have been writing a _lot_ of text about this report, but from
> > reading two sentences every second page, I was not clear about whether
> > anything has been implemented at all. What's the status of this report?
> >
> > I'm just trying to sift through the old reports and try to close that are
> > no longer valid. 1800+ non-closed reports is simply getting too many...
>
> It should be suspended, not closed. The idea is a good one, but I don't
> have time right now to actively work on it.
OK, I'll do that.
Thanks
W.
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@ticam.utexas.edu
www: http://www.ticam.utexas.edu/~bangerth
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2002-11-05 9:08 bangerth
0 siblings, 0 replies; 17+ messages in thread
From: bangerth @ 2002-11-05 9:08 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, rfg
Synopsis: gcc/g++ should stick compilation options into the .o file
State-Changed-From-To: open->suspended
State-Changed-By: bangerth
State-Changed-When: Tue Nov 5 09:08:12 2002
State-Changed-Why:
Following Phil's suggestion, I suspend this one.
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2678
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2002-11-05 9:06 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2002-11-05 9:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: rfg@monkeys.com, gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Tue, 5 Nov 2002 12:04:51 -0500
[ note that the pedwards address is now invalid ]
On Tue, Nov 05, 2002 at 09:41:10AM -0600, Wolfgang Bangerth wrote:
> Phil, Ronald,
> you two have been writing a _lot_ of text about this report, but from
> reading two sentences every second page, I was not clear about whether
> anything has been implemented at all. What's the status of this report?
>
> I'm just trying to sift through the old reports and try to close that are
> no longer valid. 1800+ non-closed reports is simply getting too many...
It should be suspended, not closed. The idea is a good one, but I don't
have time right now to actively work on it.
Phil
--
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
- Edsger Dijkstra, 1930-2002
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-05-07 16:56 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-05-07 16:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Mon, 7 May 2001 18:33:36 -0400
On Tue, May 01, 2001 at 12:36:01AM -0000, Ronald F. Guilmette wrote:
> OK. So now _here_ is a good excuse to come up with a new GNU invention...
> a new ``GNU standardized'' ELF section name.
Given the overly-loose hammer and nail analogy that you sent me in private
email, I'll assume you're being facetious here. :-)
> 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!
Actually, my current implementation already does this. I needed to figure
out where an extra copy of the options was coming from, and I left the code
in when I was done.
And I've never tried writing a tool using the BFD library, but if I
understand its purpose correctly, it should be easy to use it to write a
build-option-pretty-printer for an executable. It's on that part of my
TODO list titled, "probably useless but would be really fun to try."[*]
Phil
[*] Much of my life is under this category, so there's a good chance that
this tool would be written, if I haven't misunderstood BFD.
--
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 17:36 Ronald F. Guilmette
0 siblings, 0 replies; 17+ messages in thread
From: Ronald F. Guilmette @ 2001-04-30 17:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 17:16 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-30 17:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 10:26 Ronald F. Guilmette
0 siblings, 0 replies; 17+ messages in thread
From: Ronald F. Guilmette @ 2001-04-30 10:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: gcc-gnats@gcc.gnu.org, pedwards@disaster.jaj.com
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Mon, 30 Apr 2001 10:21:12 -0700
In message <Pine.LNX.4.32.0104301813300.17624-100000@kern.srcf.societies.cam.ac
.uk>, you wrote:
>On 30 Apr 2001, Ronald F. Guilmette wrote:
>
>> As I noted, they can always run `strip' after the compile, if the extra
>> info really bothers them.
>
>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.
b) In practice, nobody will give a damn about the presence or absense of
this extra information anyway.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 9:46 Ronald F. Guilmette
0 siblings, 0 replies; 17+ messages in thread
From: Ronald F. Guilmette @ 2001-04-30 9:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Mon, 30 Apr 2001 09:42:02 -0700
In message <20010430040740.A31126@disaster.jaj.com>, you wrote:
>On Mon, Apr 30, 2001 at 09:16:00AM -0000, Ronald F. Guilmette wrote:
>> >After some sleep, I've concluded that my original idea of using the
>> >print_switch_values routine might be stupid. I don't think people would l
>ike
>[...]
>> >showing up in their object files, for example. (Or do you?)
>>
>> Yes, it would be perfectly OK to put that all into a .comment or .note
>> section. Those sections DO NOT get loaded into main memory at run time,
>> and if necessary, `strip' and be used to remove them after the .o is built.
>
>I know they don't have SHF_ALLOC set, I was concerned with diskspace.
>Which is probably cheap enough to not be worth caring about, on further
>reflection.
Correct.
>For that matter, I had planned to have this controlled by a flag,
>on by default. People really low on space can always use the flag.
>(something like -fno-note-options)
I don't see that as either necessary or useful.
As I noted, they can always run `strip' after the compile, if the extra
info really bothers them.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 2:36 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-30 2:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Mon, 30 Apr 2001 04:07:40 -0400
On Mon, Apr 30, 2001 at 09:16:00AM -0000, Ronald F. Guilmette wrote:
> >After some sleep, I've concluded that my original idea of using the
> >print_switch_values routine might be stupid. I don't think people would like
[...]
> >showing up in their object files, for example. (Or do you?)
>
> Yes, it would be perfectly OK to put that all into a .comment or .note
> section. Those sections DO NOT get loaded into main memory at run time,
> and if necessary, `strip' and be used to remove them after the .o is built.
I know they don't have SHF_ALLOC set, I was concerned with diskspace.
Which is probably cheap enough to not be worth caring about, on further
reflection.
For that matter, I had planned to have this controlled by a flag,
on by default. People really low on space can always use the flag.
(something like -fno-note-options)
--
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-30 2:16 Ronald F. Guilmette
0 siblings, 0 replies; 17+ messages in thread
From: Ronald F. Guilmette @ 2001-04-30 2:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Mon, 30 Apr 2001 02:09:48 -0700
In message <20010429214104.A29946@disaster.jaj.com>, you wrote:
>After some sleep, I've concluded that my original idea of using the
>print_switch_values routine might be stupid. I don't think people would like
>
> options passed: -iprefix -D__GNUC__=3 -D__GNUC_MINOR__=1
> -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__
> -D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED__=1
> -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__
> -D__tune_pentiumpro__ -D__GNUG__=3 -D_GNU_SOURCE -D__DEPRECATED
> -D__EXCEPTIONS -D__GXX_ABI_VERSION=100
> options enabled: -fpeephole -ffunction-cse -fkeep-static-consts
> -fpcc-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec
> -fbranch-count-reg -fexceptions -fcommon -fgnu-linker -fargument-alias
> -fident -fmath-errno -ftrapping-math -m80387 -mhard-float
> -mno-soft-float -mieee-fp -mfp-ret-in-387
>
>showing up in their object files, for example. (Or do you?)
Yes, it would be perfectly OK to put that all into a .comment or .note
section. Those sections DO NOT get loaded into main memory at run time,
and if necessary, `strip' and be used to remove them after the .o is built.
>The kicker is that the driver doesn't pass down the set of command-line
>options directly to the compiler. It does some translations on them,
>and then adds a bunch of defaults, and then passes /all/ of that down.
That might still be OK. It's better than not having the info at all!
>(Side note: the "options enabled" block are everything that's on by
>default, as modified by the "options passed". If you really wanted to
>re-create the compilation environment for a particular file, you'd need
>to use all of those. The defaults might have changed.)
Good point.
>The compiler does have available a save_argv and save_argc, but that's how
>the "options passed" block is constructed in the first place. We don't
>have any obvious way of distinguishing which options the user passed from
>the default ones added by the specs file.
I don't believe that it is important to draw that distinction anyway.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-29 20:06 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-29 20:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Sun, 29 Apr 2001 21:41:04 -0400
On Sun, Apr 29, 2001 at 06:56:00PM -0000, Ronald F. Guilmette wrote:
> My alopogies if my slippery fingers typed in `.command' when I intended
> to write `.comment'.
:-)
> For documentation of the intended usage and format of data in ELF .note
> and .comment sections, you will need to refer to the original AT&T docu-
> mentation of ELF.
[...]
> but when I glanced again at the original AT&T documentation on ELF the other
> day, it appears to me that the contents of .note is supposed to be, in
> effect, a set of name/value pairs (vaguely reminicent of UNIX environment
> variables). The required ``structure'' of the .note section just tells
> you where and how to encode one of these name/value pairs, in general.
Yep. Just before I left last night (er, this morning), I pulled up
wotsit.org and grabbed the ELF 1.1 spec. Useful site, that.
After some sleep, I've concluded that my original idea of using the
print_switch_values routine might be stupid. I don't think people would like
options passed: -iprefix -D__GNUC__=3 -D__GNUC_MINOR__=1
-D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__
-D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED__=1
-Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__
-D__tune_pentiumpro__ -D__GNUG__=3 -D_GNU_SOURCE -D__DEPRECATED
-D__EXCEPTIONS -D__GXX_ABI_VERSION=100
options enabled: -fpeephole -ffunction-cse -fkeep-static-consts
-fpcc-struct-return -fgcse-lm -fgcse-sm -fsched-interblock -fsched-spec
-fbranch-count-reg -fexceptions -fcommon -fgnu-linker -fargument-alias
-fident -fmath-errno -ftrapping-math -m80387 -mhard-float
-mno-soft-float -mieee-fp -mfp-ret-in-387
showing up in their object files, for example. (Or do you?)
The kicker is that the driver doesn't pass down the set of command-line
options directly to the compiler. It does some translations on them,
and then adds a bunch of defaults, and then passes /all/ of that down.
See the "options passed" block above, for example; all of those are
options to the compiler that the driver is inserting. If I had used
-fomit-frame-pointer, for example, then that would be at the end of the
list after the -D__*'s.
(Side note: the "options enabled" block are everything that's on by
default, as modified by the "options passed". If you really wanted to
re-create the compilation environment for a particular file, you'd need
to use all of those. The defaults might have changed.)
The compiler does have available a save_argv and save_argc, but that's how
the "options passed" block is constructed in the first place. We don't
have any obvious way of distinguishing which options the user passed from
the default ones added by the specs file.
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-29 11:56 Ronald F. Guilmette
0 siblings, 0 replies; 17+ messages in thread
From: Ronald F. Guilmette @ 2001-04-29 11:56 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Sun, 29 Apr 2001 11:47:39 -0700
In message <20010429055624.A28542@disaster.jaj.com>, you wrote:
>On Sat, Apr 28, 2001 at 08:36:49PM -0000, rfg@monkeys.com wrote:
>> And I don't think that it would
>> be very hard to get the front-end gcc/g++ driver to pass
>> ALL compilation options down to cc1 and/or cc1plus.
>
>We already do...
How convenient!
>> They
>> in turn could easily still the options into a suitable ELF
>> section.
>
>I can't see any obvious documentation of .note sections in the gas source,
>and I don't see .command mentioned at all. I wouldn't mind playing with this
>idea while waiting on compiles, if you can point me towards some usage docs.
My alopogies if my slippery fingers typed in `.command' when I intended
to write `.comment'.
For documentation of the intended usage and format of data in ELF .note
and .comment sections, you will need to refer to the original AT&T docu-
mentation of ELF. I know that documentation (in various non-modified
and slightly modified forms) is available on the web in various places,
because I found it on the web in several places when I went looking for
it a couple of months ago.
I'll find a URL or two for you if you need them. Just let me know.
Stuff that is placed into ELF .note sections is supposed to obey a very
well defined format. However stuff in .comment sections is more in the
nature of just free-form text lines, I believe. I can't remember anymore.
What gets put into a .note section is basically 100% implementation defined,
but when I glanced again at the original AT&T documentation on ELF the other
day, it appears to me that the contents of .note is supposed to be, in
effect, a set of name/value pairs (vaguely reminicent of UNIX environment
variables). The required ``structure'' of the .note section just tells
you where and how to encode one of these name/value pairs, in general.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-29 5:46 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-29 5:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Phil Edwards <pedwards@disaster.jaj.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Sun, 29 Apr 2001 07:20:29 -0400
On Sun, Apr 29, 2001 at 01:26:53PM +0100, Joseph S. Myers wrote:
> On 29 Apr 2001, Phil Edwards wrote:
> > I think that's .ident, not .comment. (Was ".command" a typo for ".comment"?)
>
> .ident assembler directives put data in .comment.
Duh... this is what happens when I post without sleep.
> Since the original message mentioned both .comment and .command, I think
> .command did mean .comment.
Pity, a .command section would've been useful for this.
--
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-29 5:16 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-29 5:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Phil Edwards <pedwards@disaster.jaj.com>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Sun, 29 Apr 2001 06:50:29 -0400
On Sun, Apr 29, 2001 at 11:56:01AM -0000, Joseph S. Myers wrote:
> On 29 Apr 2001, Phil Edwards wrote:
>
> > I can't see any obvious documentation of .note sections in the gas source,
> > and I don't see .command mentioned at all. I wouldn't mind playing with this
> > idea while waiting on compiles, if you can point me towards some usage docs.
>
> .note is where GCC used to output the useless "01.01" strings for every
> file. .commment is where it outputs the compiler version string.
I think that's .ident, not .comment. (Was ".command" a typo for ".comment"?)
> As with
> the compiler version string, compilation options are useful information.
I just implemented this, sort of. At least, it switches to the .note
section, but then just spews text. What would the correct directive be
at that point? .ascii?
Um, there's a /lot/ of text produced from print_switch_values. This sounds
like something we'd like to have on by default, but that's about fifteen
lines of options.
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-29 4:16 Phil Edwards
0 siblings, 0 replies; 17+ messages in thread
From: Phil Edwards @ 2001-04-29 4:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR c/2678; it has been noted by GNATS.
From: Phil Edwards <pedwards@disaster.jaj.com>
To: rfg@monkeys.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c/2678: gcc/g++ should stick compilation options into the .o file
Date: Sun, 29 Apr 2001 05:56:24 -0400
On Sat, Apr 28, 2001 at 08:36:49PM -0000, rfg@monkeys.com wrote:
> And I don't think that it would
> be very hard to get the front-end gcc/g++ driver to pass
> ALL compilation options down to cc1 and/or cc1plus.
We already do; see print_switch_values in toplev.c for an example usage.
In verbose mode, almost all the switches are dumped to stderr; if
-fverbose-asm is used, they are dumped as comments to the assembly file.
I say "dumped" when they're actually formatted nicely. And I say "almost"
all the switches because the language-specific ones can't be seen.
(I tried cleaning this up once for this specific purpose, but it involved
touching a lot of files, and nobody was interested.)
> They
> in turn could easily still the options into a suitable ELF
> section.
I can't see any obvious documentation of .note sections in the gas source,
and I don't see .command mentioned at all. I wouldn't mind playing with this
idea while waiting on compiles, if you can point me towards some usage docs.
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.
^ permalink raw reply [flat|nested] 17+ messages in thread
* c/2678: gcc/g++ should stick compilation options into the .o file
@ 2001-04-28 13:46 rfg
0 siblings, 0 replies; 17+ messages in thread
From: rfg @ 2001-04-28 13:46 UTC (permalink / raw)
To: gcc-gnats
>Number: 2678
>Category: c
>Synopsis: gcc/g++ should stick compilation options into the .o file
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Sat Apr 28 13:46:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: Ronald F. Guilmette
>Release: gcc-2.95.2
>Organization:
>Environment:
>Description:
It would be Really Nice if the gcc and g++ compilers, when
compiling for some ELF target (at least) would stick a
copy of ALL of the compilation options used during the
compile into an ELF .comment or .note section within the
resulting .o file.
I wish I had a nickle for every time I had a .o file, left
over from some build I did a long long time ago (in a galaxy
not far away) and I was stuck saying to myself ``I wish I
knew what options this thing had been compiled with. I wonder
if it was optimized.''
The ELF object file format provides a couple of obvious means
(.command and .note sections) for recording this exact infor-
mation into each .o file. And I don't think that it would
be very hard to get the front-end gcc/g++ driver to pass
ALL compilation options down to cc1 and/or cc1plus. They
in turn could easily still the options into a suitable ELF
section.
Note that this would also allow for some potentially inter-
esting types of retrospective automated analysis of .o files.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2002-11-05 17:16 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-11-05 7:46 c/2678: gcc/g++ should stick compilation options into the .o file Wolfgang Bangerth
-- strict thread matches above, loose matches on Subject: below --
2002-11-05 9:16 Wolfgang Bangerth
2002-11-05 9:08 bangerth
2002-11-05 9:06 Phil Edwards
2001-05-07 16:56 Phil Edwards
2001-04-30 17:36 Ronald F. Guilmette
2001-04-30 17:16 Phil Edwards
2001-04-30 10:26 Ronald F. Guilmette
2001-04-30 9:46 Ronald F. Guilmette
2001-04-30 2:36 Phil Edwards
2001-04-30 2:16 Ronald F. Guilmette
2001-04-29 20:06 Phil Edwards
2001-04-29 11:56 Ronald F. Guilmette
2001-04-29 5:46 Phil Edwards
2001-04-29 5:16 Phil Edwards
2001-04-29 4:16 Phil Edwards
2001-04-28 13:46 rfg
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).