[llvm-dev] Embedding LLD version to executables

Wed Oct 19 02:19:12 PDT 2016

My understanding is that a note section is primarily for recording
information needed for conformance rather than communicating the
version of the tool. Although I think the distinction is somewhat
arbitrary in practice.

I believe many compilers put version information in the .comment
section already. For example the linaro gcc puts its version string
there. GCC: (Linaro GCC 5.3-2016.02) 5.3.1 20160113

Speaking from experience, In ARM's proprietary toolchain we used the
.comment section to record information including the version number
and the command line used from all the tools. Curiously enough it was
often the compiler/assembler information that had been combined into
the final .comment section that was most useful in troubleshooting.
The disadvantage of recording so much information in the .comment
sections was that the linker had to do some kind of processing of the
.comment section contents to common up the information.

To summarise I think a note section would be most useful if the format
of the version string never changed and was read and checked by other
tools. A .comment section would be more suitable for free form
information.

Peter

http://www.sco.com/developers/gabi/latest/ch4.sheader.html
http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_section

On 19 October 2016 at 05:43, Hal Finkel via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> ________________________________
>
> From: "Mehdi Amini" <mehdi.amini at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" <ruiu at google.com>
> Sent: Tuesday, October 18, 2016 11:35:02 PM
>
> Subject: Re: [llvm-dev] Embedding LLD version to executables
>
>
> On Oct 18, 2016, at 9:27 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
>
> ________________________________
>
> From: "Mehdi Amini" <mehdi.amini at apple.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Rui Ueyama" <ruiu at google.com>
> Sent: Tuesday, October 18, 2016 10:38:57 PM
> Subject: Re: [llvm-dev] Embedding LLD version to executables
>
>
> On Oct 18, 2016, at 8:30 PM, Hal Finkel <hfinkel at anl.gov> wrote:
>
> ________________________________
>
> From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Rui Ueyama" <ruiu at google.com>
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, October 18, 2016 10:22:00 PM
> Subject: Re: [llvm-dev] Embedding LLD version to executables
>
>
> On Oct 18, 2016, at 6:44 PM, Rui Ueyama via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
> I'd like to make LLD embed version information so that we can
> determine if an executable was created by LLD and if that's the
> case which version of LLD.
>
>
> Pardon my ignorance, but what’s the motivation?
>
> We don’t embed the clang version in every binary clang generates for
> instance.
>
>
> We do. Clang outputs an "ident" comment with its version information, and
> that ends up in the object files (at least on Linux).
>
>
> Interesting, we don’t on Darwin:
>
> $ echo "int main() {}" | clang -x c -o - - -S  | grep clang
> $ echo "int main() {}" | clang -x c -o - - -S -target x86_64-pc-linux-gnu |
> grep clang
> .ident "Apple LLVM version 8.0.0 (clang-800.0.42.1)”
>
> Dos it show up in the final binary?
>
> Yes
>
> If yes, how does it behave when you mix-and-match versions in different .o?
>
> I see both versions in the final binary.
>
>
> Pretty cool! Thanks for looking.
>
> Is there a trace in the binary the list of object files for each version? I
> guess that’d be more costly to store.
>
> As far as I can tell, the version strings all get concatenated in the
> .comment section of the resulting executable. The strings are
> null-terminated, and so there is a null byte separating the strings. For
> example, objdump -x -s shows this from my test:
>
> Contents of section .comment:
>  0000 4743433a 2028474e 55292034 2e382e35  GCC: (GNU) 4.8.5
>  0010 20323031 35303632 33202852 65642048   20150623 (Red H
>  0020 61742034 2e382e35 2d342900 636c616e  at 4.8.5-4).clan
>  0030 67207665 7273696f 6e20342e 302e3020  g version 4.0.0
>  0040 28687474 703a2f2f 6c6c766d 2e6f7267  (http://llvm.org
>  0050 2f676974 2f636c61 6e672e67 69742036  /git/clang.git 6
>  0060 31653732 36613362 63633664 34633262  1e726a3bcc6d4c2b
>  0070 35346330 30366337 61623762 31316133  54c006c7ab7b11a3
>  0080 33613034 32613629 20286874 74703a2f  3a042a6) (http:/
>  0090 2f6c6c76 6d2e6f72 672f6769 742f6c6c  /llvm.org/git/ll
>  00a0 766d2e67 69742061 62383338 37303961  vm.git ab838709a
>  00b0 63356330 35623262 36393031 65366630  c5c05b2b6901e6f0
>  00c0 65303964 65613561 35356636 36333729  e09dea5a55f6637)
>  00d0 00636c61 6e672076 65727369 6f6e2033  .clang version 3
>  00e0 2e392e30 20286874 74703a2f 2f6c6c76  .9.0 (http://llv
>  00f0 6d2e6f72 672f6769 742f636c 616e672e  m.org/git/clang.
>  0100 67697420 30373330 37663935 64356338  git 07307f95d5c8
>  0110 32643435 33636463 35633233 66396363  2d453cdc5c23f9cc
>  0120 64353364 35666637 35343236 29202868  d53d5ff75426) (h
>  0130 7474703a 2f2f6c6c 766d2e6f 72672f67  ttp://llvm.org/g
>  0140 69742f6c 6c766d2e 67697420 30333136  it/llvm.git 0316
>  0150 66303235 64616234 36643737 36646565  f025dab46d776dee
>  0160 37306433 62363935 65316130 37646235  70d3b695e1a07db5
>  0170 33373163 2900                        371c).
>
>  -Hal
>
>
> —
> Mehdi
>
>
>
> Also I’m still not sure why doing this?
>
> —
> Mehdi
>
>
>
>
> ld.bfd doesn't seem to embed any information, so we cannot tell
> whether an executable was linked by ld.bfd or not easily.
>
> ld.gold embeds a string "GNU gold <version>" as
> ".note.gnu.gold-version" section contents.
>
> I'm wondering what we should do for LLD. The gold's way seems
> almost right, but I think we don't want to use the same section
> name because it contains "gold" as part of the section name.
> However, at the same time, I don't believe we want to create
> ".note.gnu.lld-version", because if we do, all programs that
> determine linker version need to look at
> ".note.gnu.<linker-name>-version" for all known linkers. That's
> absurd. (Also, our product is not GNU, so ".gnu" part is probably
> irrelevant.)
>
> I'm leaning towards ".note.linker-version" in hope that other
> linkers follow it.
>
>
> At least that would look much better than a .gnu.xxxx
>
>
> I agree.
>
> -Hal
>
>
> —
> Mehdi
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
>
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
>
>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>