From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25941 invoked by alias); 6 Aug 2007 08:12:49 -0000 Received: (qmail 25260 invoked by alias); 6 Aug 2007 08:12:31 -0000 Date: Mon, 06 Aug 2007 08:12:00 -0000 Message-ID: <20070806081231.25259.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug other/32998] -frecord-gcc-switches issues In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "nickc at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-08/txt/msg00331.txt.bz2 ------- Comment #1 from nickc at redhat dot com 2007-08-06 08:12 ------- Subject: Re: New: -frecord-gcc-switches issues Hi Jakub, > .ascii "-isystem ./include-fixed" > .zero 1 > .ascii "-D_GNU_SOURCE a.c" > .zero 1 > The main issue I have with this is the separation of options into separate > strings (though, look above at "-D_GNU_SOURCE a.c" string to see it is not > done always anyway). Right - I could not find 100% effective heuristic to work out when a "word" on the command line was the argument to a previous command line option or a separate option in its own right. The current heuristic assumes that if the word does not start with a dash, then it is an argument to previous word. Hence "./include-fixed" is correctly taken as an argument to "-isystem" but "a.c" is mistakenly taken as an argument to "-D_GNU_SOURCE". I think that in order to fix this the .GCC.command.line section creation code will have to be made more complex and have access to the entire command line options table. When I submitted the original patch to create this feature I wanted to keep things simple, so I did not try to do this. > On the other side, if you have one big string with all command > line options (but one that should not reference the source file name [snip] > ) then you can query whether each source was compiled with -fstack-protector > or not, etc. Except that you will not have the source file names in the strings. So if one or more of the component objects were not compiled with -fstack-protector you then have to go through several more hoops in order to find out which ones they are. > (but one that should not reference the source file name and IMNSHO > not even any of the -I/-iprefix/-isystem options, that's what .debug_line is > for and in this section where you no longer know which filename was it and > which directory was it in I can't see what it would be useful for) Personally I think that the pathname information (source files and include directories) should be left in, since it is pertinent to how the object file was created. (Yes you can track this information down from the .debug_line section, but that is more hassle if you are already looking at the .GCC.command.line section for the other options used to make the object file). I agree that relative pathnames in this information may not be very useful, but it should be possible to convert all relative paths into absolute paths as the .GCC.command.line section is generated. > -frecord-gcc-switches among the saved options doesn't make sense either (if it > was not used, they wouldn't be recorded). True. But I was working on the keep-it-simple principle when I wrote the code. Also it seems to me that not displaying it would be opening the door to censoring the command line. If we do not record the -frecord-gcc-switches option then we have established the principle that some options are not recorded. So maybe the -I options should be skipped as well. Then maybe the -O switches can be ignored (everyone uses optimization, right ?) I am exaggerating of course, but my point is, once we start censoring the command line, the consumers of .GCC.command.line can no longer trust it to contain a full and accurate record of how the object file was compiled. As a theoretical example of why this might be important, suppose that there was a bug whereby cc1 would ignore any command line options beyond argv[511], because of some system limitation. If we did not record the full command line in the .GCC.command.line section then someone using the information in the section to try to reproduce the bug might not be able to do so, because their command line would be shorter. Having said all that I am happy to see this feature improved so please do submit patches for it. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998