This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/32998] -frecord-gcc-switches issues
- From: "nickc at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 7 Aug 2007 08:25:37 -0000
- Subject: [Bug other/32998] -frecord-gcc-switches issues
- References: <bug-32998-87@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #5 from nickc at redhat dot com 2007-08-07 08:25 -------
Subject: Re: -frecord-gcc-switches issues
Hi Ben,
> Is there an easy way to separate out the include and link (-I, -L) bits from
> the macro defines and compiler option flags? Could the just the include bits be
> put into one string?
Sure. We could add some intelligence to the recording function which looks for
these switches and groups them all together. There are quite a lot of them
though: -B, -I, -J, -L, -iquote, -isystem, -include, -imacros, -idirafter,
-iwithprefixbefore, -imultilib, -isysroot.
> When doing this does it make sense to define the base_dir and then use it as a
> substitution instead of putting in absolute addresses everywhere? This might
> cut down on size.
Well that sounds like a good idea to me. But Roland was objecting to recording
absolute paths of any kind, so he might not like this.
>> 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.
> However.... can you expand on your comment above? What do you mean by "have
> access to the entire command line options table?" Would you dump the entire
> table?
Oh no. What I meant was that in order for the recording code to be more
intelligent it would need access to gcc's command line options structure, so
that, for example, it can tell when a switch takes an argument (and hence
correctly deduce whether an entry in the argv[] array should be included in the
same string as the previous entry or if it is a new command line switch in its
own right). Access to this table would also make it possible to do things
like:
* group all the optimization switches together in one part of the
.GCC.command.line section.
* locate switches which negate the effect of previous switches and then skip
recording those previous switches.
My concern however is that adding this sort of thing complicates the code, and
hence is more likely to introduce bugs. Still if it makes the feature useful,
then it is worth considering.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998