Re: [PATCH v2 0/3] Introduce a new GCC option, --record-gcc-command-line

[Richard Biener <richard.guenther@gmail.com>]

On Wed, Mar 4, 2020 at 5:28 PM Egeyar Bagcioglu
<egeyar.bagcioglu@oracle.com> wrote:
>
>
>
> On 3/4/20 1:18 AM, Fangrui Song wrote:
> > On 2020-03-03, Joseph Myers wrote:
> >> On Tue, 3 Mar 2020, Egeyar Bagcioglu wrote:
> >>
> >>> Although we discussed after the submission of the first version that
> >>> there are several other options performing similar tasks, I believe we
> >>> established that there is still a need for this specific functionality.
> >>> Therefore, I am skipping in this email the comparison between this
> >>> option and the existing options with similarities.
> >
> > Mentioning -frecord-gcc-switches will be much appreciated.
> >
> > How is the new .GCC.command.line different?
> >
> > Does it still have the SHF_MERGE | SHF_STRINGS flag?
> > If you change the flags, the .GCC.command.line section may not play with
> > another object file (generated by -frecord-gcc-switches) whose
> > .GCC.command.line is
> > SHF_MERGE | SHF_STRINGS.
> >
> > When both -frecord-gcc-switches and --record-command-line are specified,
> > is it an error?
>
> This option is similar to -frecord-gcc-switches. However, they have
> three fundamental differences: Firstly, -frecord-gcc-switches saves the
> internal state after the argv is processed and passed by the driver. As
> opposed to that, --record-gcc-command-line saves the command-line as
> received by the driver, with the exception of extending @files first.
> Secondly, -frecord-gcc-switches saves the switches as separate entries
> into a mergeable string section. Therefore, the entries belonging to
> different object files get mixed up after being linked. The new
> --record-gcc-command-line, on the other hand, creates one entry per
> invocation. By doing so, it makes it clear which options were used
> together in a single gcc invocation. Lastly, --record-gcc-command-line
> also adds the version of the gcc into this single entry to make it clear
> which version of gcc was called with any given command line. This is
> useful in cases where .comment section reports multiple versions.
>
> While there are also similarities between the implementations of these
> two options, those implementations are completely independent. These
> commands can be used separately or together without issues. I used the
> same section that -frecord-gcc-switches uses on purpose, so that they
> can also be used together to save both the command line given to GCC and
> the internal switches passed by GCC.
>
> The option -grecord-gcc-switches is similar to -frecord-gcc-switches,
> but saves the internal GCC switches into DWARF. Lastly, -fverbose-asm
> option saves the switches into the assembly file but that information
> never makes it to the object files.

-grecord-gcc-switches also allows to match the options used to the
actual generated code while both -frecord-gcc-switches and
--record-gcc-command-line
end up as ELF comment sections not associated with particular
code pieces.

So IMHO anything but -grecord-gcc-switches is quite useless in case options
used do not match for all object files.

Richard.

> >
> >> We're now using git-style commit messages with self-contained
> >> explanation
> >> / justification of the change being committed.
> >>
> >> This means that one of the commit messages (not just message 0, whose
> >> contents don't go in a commit message) for an individual patch should
> >> have
> >> the explanation, which should include the self-contained
> >> justification by
> >> reference to comparison with other existing similar options. People
> >> should be able to find the relevant information in the commit without
> >> needing to search the list archives for reviews of a previous patch
> >> version.
>
> Thanks for telling me. I will extend the above comparison according to
> the questions I might receive. Then I'll add it, together with the
> explanation in the cover letter, into the commit message of the second
> patch.
>
> Regards
> Egeyar