llvm dev - Oct 2016 - Embedding LLD version to executables

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>

Hi,
> 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.

Can't you use -v to see what linker the compiler driver invoked?


On Wed, Oct 19, 2016 at 4:41 AM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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
>>
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161019/71783353/attachment.html>

On Wed, Oct 19, 2016 at 3:39 AM, Dave Bozier via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> > 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.
>
> Can't you use -v to see what linker the compiler driver invoked?
>
Sometimes, things are buried very deep in a build system, such that
extracting the clang invocation is difficult.

-- Sean Silva

>
>
> On Wed, Oct 19, 2016 at 4:41 AM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161029/a59f5a06/attachment.html>