On 3/4/20 5:28 PM, Egeyar Bagcioglu 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.
I should add here that both Martin Liska and Nick Clifton mentioned
during the last round of discussion the importance of capturing options
such as -D_FORTIFY_SOURCE which is apparently not distinguished by
--frecord-gcc-switches. The option I am suggesting,
--record-gcc-command-line, saves that without any special case handling.
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.
Here is an old example from the previous discussion, calling g++ with
both -frecord-gcc-switches and --record-gcc-command-line for comparison:
[egeyar@localhost save-commandline]$ g++ main.c
--record-gcc-command-line -frecord-gcc-switches
[egeyar@localhost save-commandline]$ readelf -p .GCC.command.line a.out
String dump of section '.GCC.command.line':
[ 0] 10.0.0 20191025 (experimental) : g++ main.c
--record-gcc-command-line -frecord-gcc-switches
[ 5c] -D_GNU_SOURCE
[ 6a] main.c
[ 71] -mtune=generic
[ 80] -march=x86-64
[ 8e] --record-gcc-command-line /tmp/ccgC4ZtS.cmdline
Above, the first entry in the .GCC.command.line section is saved by
--record-gcc-command-line; while the rest of the entries are added by
-frecord-gcc-switches.
Regards
Egeyar
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
