[llvm-dev] Embedding LLD version to executables

[Rui Ueyama via llvm-dev]

On Tue, Oct 18, 2016 at 8:22 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:

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

It should make trouble shooting linker issues easier. Here are a few
scenarios.

Scenario 1: you added -fuse-ld=lld to your command line, but you are
suspecting that the option is ignored. Currently, it's actually
surprisingly hard to tell if an output was created by LLD.

Scenario 2: someone reported an issue about an executable linked by LLD,
and we know that version X has a similar bug, then the first thing we want
to do is to check if the executable was created with version X.


>
> We don’t embed the clang version in every binary clang generates for
> instance.
>
> >
> > 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
>
> —
> Mehdi
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161018/861be71d/attachment.html>