This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/32998] -frecord-gcc-switches issues



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]