ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
# REQUIRES: x86
|
|
|
|
|
|
|
|
|
|
# RUN: llvm-mc -filetype=obj -triple=x86_64-unknown-linux %s -o %t
|
|
|
|
|
# RUN: ld.lld --build-id %t -o %t2
|
2016-04-08 06:49:21 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
|
|
|
|
|
# RUN: ld.lld --build-id=md5 %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=MD5 %s
|
2016-04-08 07:51:56 +08:00
|
|
|
# RUN: ld.lld --build-id=sha1 %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
|
2016-05-14 05:55:56 +08:00
|
|
|
# RUN: ld.lld --build-id=0x12345678 %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=HEX %s
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
# RUN: ld.lld %t -o %t2
|
2016-04-08 06:49:21 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
|
2016-05-04 04:55:47 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 --build-id=none %t -o %t2
|
|
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
|
2016-04-27 10:58:27 +08:00
|
|
|
.globl _start
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
_start:
|
|
|
|
|
nop
|
|
|
|
|
|
2016-03-13 09:54:48 +08:00
|
|
|
.section .note.test, "a", @note
|
|
|
|
|
.quad 42
|
|
|
|
|
|
2016-04-08 06:49:21 +08:00
|
|
|
# DEFAULT: Contents of section .note.gnu.build-id:
|
|
|
|
|
# DEFAULT-NEXT: 04000000 08000000 03000000 474e5500 ............GNU.
|
|
|
|
|
# DEFAULT: Contents of section .note.test:
|
ELF: Implement --build-id.
This patch implements --build-id. After the linker creates an output file
in the memory buffer, it computes the FNV1 hash of the resulting file
and set the hash to the .note section as a build-id.
GNU ld and gold have the same feature, but their default choice of the
hash function is different. Their default is SHA1.
We made a deliberate choice to not use a secure hash function for the
sake of performance. Computing a secure hash is slow -- for example,
MD5 throughput is usually 400 MB/s or so. SHA1 is slower than that.
As a result, if you pass --build-id to gold, then the linker becomes about
10% slower than that without the option. We observed a similar degradation
in an experimental implementation of build-id for LLD. On the other hand,
we observed only 1-2% performance degradation with the FNV hash.
Since build-id is not for digital certificate or anything, we think that
a very small probability of collision is acceptable.
We considered using other signals such as using input file timestamps as
inputs to a secure hash function. But such signals would have an issue
with build reproducibility (if you build a binary from the same source
tree using the same toolchain, the build id should become the same.)
GNU linkers accepts --build-id=<style> option where style is one of
"MD5", "SHA1", or an arbitrary hex string. That option is out of scope
of this patch.
http://reviews.llvm.org/D18091
llvm-svn: 263292
2016-03-12 04:51:53 +08:00
|
|
|
|
2016-04-08 06:49:21 +08:00
|
|
|
# MD5: Contents of section .note.gnu.build-id:
|
|
|
|
|
# MD5-NEXT: 04000000 10000000 03000000 474e5500 ............GNU.
|
|
|
|
|
|
2016-04-08 07:51:56 +08:00
|
|
|
# SHA1: Contents of section .note.gnu.build-id:
|
|
|
|
|
# SHA1-NEXT: 04000000 14000000 03000000 474e5500 ............GNU.
|
|
|
|
|
|
2016-05-14 05:55:56 +08:00
|
|
|
# HEX: Contents of section .note.gnu.build-id:
|
|
|
|
|
# HEX-NEXT: 04000000 04000000 03000000 474e5500 ............GNU.
|
|
|
|
|
# HEX-NEXT: 12345678
|
|
|
|
|
|
2016-04-08 06:49:21 +08:00
|
|
|
# NONE-NOT: Contents of section .note.gnu.build-id:
|