This is an archive of the discontinued LLVM Phabricator instance.

Include version string into ".linker-version" section.
AbandonedPublic

Authored by ruiu on Oct 19 2016, 2:50 PM.

Details

Summary

This patch adds a new section, ".linker-version", to an output.
The section contains the linker's version string. You can now
find out whether a binary is created by LLD or not using objdump
command like this.

$ objdump -j .linker-version -s foo

foo:     file format elf64-x86-64

Contents of section .linker-version:
 0000 4c4c4420 342e3020 28687474 70733a2f  LLD 4.0 (https:/
 0010 2f6c6c76 6d2e6f72 672f7376 6e2f6c6c  /llvm.org/svn/ll
 0020 766d2d70 726f6a65 63742f6c 6c642f74  vm-project/lld/t
 0030 72756e6b 20323834 36333429 00        runk 284634).

An alternative considered:

I first tried to add a SHT_NOTE section because GNU gold does that.
A NOTE section starts with a header which contains content type.
It turned out that ld.gold sets type NT_GNU_GOLD_VERSION to their
NOTE section. So the NOTE type is only for GNU gold (surprise!)

I could define NT_GNU_LINKER_VERSION. However, I doubt that we need
a header at all. It doesn't seem useful at all. Thus, I decided to
just set a version string without any header.

Now that it is not a NOTE section, it doesn't make sense to start
a section name with ".note". So I named it just ".linker-version".

Event Timeline

ruiu updated this revision to Diff 75234.Oct 19 2016, 2:50 PM
ruiu retitled this revision from to Include version string into ".linker-version" section..
ruiu updated this object.
ruiu added a subscriber: llvm-commits.
emaste added a subscriber: emaste.Oct 19 2016, 7:17 PM

This would have been very useful to me during the initial FreeBSD - lld bring up, so I'm in favour of having a way to identify the linker that was used.

grimar added a subscriber: grimar.Oct 20 2016, 12:51 AM
peter.smith edited edge metadata.Oct 20 2016, 4:22 AM

The contents of the .linker-version section and the code create it look good to me.

My only question given that .linker-version is SHT_PROGBITS is why use a separate .linker-version section rather than just add to the pre-existing .comment section? For example in a test file built using objects from clang and gcc I get a .comment section out of lld that looks like:
Contents of section .comment:
0000 00474343 3a20284c 696e6172 6f204743 .GCC: (Linaro GC
0010 4320352e 332d3230 31362e30 32292035 C 5.3-2016.02) 5
0020 2e332e31 20323031 36303131 3300636c .3.1 20160113.cl
0030 616e6720 76657273 696f6e20 342e302e ang version 4.0.
0040 302000 0 .

Putting the information from .linker-version in the .comment section collects all the version control information for the toolchain in one place.

Having said all that I don't have a strong opinion and I'm happy to go with .linker-version if others prefer.

ruiu added a comment.Oct 20 2016, 10:59 AM

I was thinking about that. The benefit of doing that is that the .comment section is a well-known section, so the exiting tools can handle it (or strip it.) On the other hand, I worried if we add a linker version to .comment, you cannot figure out which is the linker's version string among many strings in a .comment section unless you know the name of the linker.

Probably I was overthinking. The .comment section is for human consumption, so that may a better place to put the version string than creating a new section. Let me update this patch.

.comment sounds good to me

It would be nice to have an easy way to extract the linker name from the file somehow. There doesn't seem to be an established way to encode this information now - as you observed, gold uses .note.gnu.gold-version, whereas other programs tend to use the .comment section. How about using the .comment section, but using a prefix (e.g. "linker: ", followed by the identifying string (e.g. "${program} version ${version} (${commit_info})" as we use for Clang?

ruiu added a comment.Oct 20 2016, 5:50 PM

That's a good idea. I'll add "linker:" prefix.

davide edited edge metadata.Nov 9 2016, 2:05 PM

I don't dislike the general idea, but I think you can convert this to a Synthetic Input Section (this patch predates the introduction of SyntheticSections.cpp)

ruiu added a comment.Nov 9 2016, 2:08 PM

Yes, we should convert this to synthetic input section, but we are not ready yet, because we cannot create synthetic mergeable string section yet.