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