[llvm-dev] Embedding LLD version to executables

[Hal Finkel via llvm-dev]

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