[PATCH] D54487: Implement llvm.commandline named metadata

[Scott Linder via Phabricator via llvm-commits]

scott.linder added a comment.

In D54487#1325584 <https://reviews.llvm.org/D54487#1325584>, @JohnReagan wrote:

> I'll ask the larger question of why did you pick ".LLVM.command.line" as the section name?  While distasteful, there might be existing scripts that do things like:
>
> readelf -p .GCC.command.line a.out
>
> to dump out the arguments like
>
> String dump of section '.GCC.command.line':
>
>   [     0]  a.c
>   [     4]  -mtune=generic
>   [    13]  -march=x86-64
>   [    21]  -O2
>   [    25]  -frecord-gcc-switches
>   
>
> Yes, the format of contents is not well-defined (as mentioned in the gcc man pages), but for somebody switching from a gcc-based toolchain to an LLVM-based toolchain, would they expect the sections to have the same names?
>
> Your description says this would allow clang to add -frecord-gcc-switches (and not -frecord-llvm-switches) so would someone expect that clang would follow the module and create a '.GCC.command.line' section name?
>
> Or perhaps also create a .GCC.command.line section that would contain 'see .LLVM.command.line for additional command line descriptions' so at least existing scripts might not get tripped up?
>
> Or am I overthinking this from working in a high "upward-compatibility, don't break anything" environment for 30+ years?


Looking at it again I think I agree that changing the name is not as useful as I had intended, and probably does more harm than it is worth. I originally wanted to avoid breaking the "ABI" of the section, for tools which go beyond inspecting it visually and rely on a certain binary layout (as that layout is changing), but if that format is not well-defined anyway I think preserving the name is reasonable. I will update both patches, and will be explicit in the Clang docs about the change in format.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54487/new/

https://reviews.llvm.org/D54487