Hal Finkel via llvm-dev
2016-Oct-19 04:27 UTC
[llvm-dev] Embedding LLD version to executables
----- Original Message -----> 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: >> > ----- Original Message ----- >> > > 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. -Hal> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/28775af8/attachment.html>
Mehdi Amini via llvm-dev
2016-Oct-19 04:35 UTC
[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 <mailto:mehdi.amini at apple.com>> > To: "Hal Finkel" <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>, "Rui Ueyama" <ruiu at google.com <mailto: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 <mailto:hfinkel at anl.gov>> wrote: > > > From: "Mehdi Amini via llvm-dev" <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> > To: "Rui Ueyama" <ruiu at google.com <mailto:ruiu at google.com>> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org <mailto: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 <mailto: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. — 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 <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev <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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/a03545ef/attachment.html>
Hal Finkel via llvm-dev
2016-Oct-19 04:43 UTC
[llvm-dev] Embedding LLD version to executables
----- Original Message -----> 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: >> > ----- Original Message ----- >> > > 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: > > > > > >> > > > ----- Original Message ----- > > > > > >> > > > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/308f3d03/attachment-0001.html>