Hal Finkel via llvm-dev
2016-Oct-19 03:30 UTC
[llvm-dev] Embedding LLD version to executables
----- 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).> > > > > 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.xxxxI 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
Mehdi Amini via llvm-dev
2016-Oct-19 03:38 UTC
[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? If yes, how does it behave when you mix-and-match versions in different .o? 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/ad5dbab1/attachment.html>
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>