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