[llvm-dev] Embedding LLD version to executables

[Mehdi Amini via llvm-dev]

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