On 3/5/20 8:36 AM, Richard Biener wrote:
On Wed, Mar 4, 2020 at 5:28 PM Egeyar Bagcioglu
<egeyar.bagcio...@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.
I hear that. I am definitely not arguing against the use cases where
-grecord-gcc-switches is the best option. But this patch is coming from
the point of view of a different use case at hand. We need to have the
frontend command line saved in a way that it can be later extracted from
the ELF object (including shared libraries and binaries) and be used to
re-compile individual objects, producing more or less the same generated
code. This patch is not enough to get the exact same output, but it is
necessary for us.
Correct me if I am wrong, but none of the existing options are very
helpful when it comes to asking gcc to do the same thing that it did
while creating that object. They hint some things about the command line
but do not help much reconstructing the command line. That is what I
mean when I say this option is not about the internals of gcc. It is
definitely not about knowing what's passed to the backend. As long as
this option's output is concerned, gcc is a blackbox. This is about the
command-line, about higher-level users' interaction with the driver and
nothing more.
Best regards
Egeyar
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
