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
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2017-10-31 06:08:11 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2
|
2019-05-01 13:49:01 +08:00
|
|
|
# RUN: llvm-readobj -S %t2 | FileCheck -check-prefix=ALIGN %s
|
2017-10-31 06:08:11 +08:00
|
|
|
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=fast %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id %t -o %t2 --threads=1
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=MD5 %s
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 %t -o %t2 --threads=1
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=MD5 %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=sha1 %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=SHA1 %s
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=sha1 %t -o %t2 --threads=1
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=SHA1 %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=tree %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=SHA1 %s
|
[lld][COFF][ELF][WebAssembly] Replace --[no-]threads /threads[:no] with --threads={1,2,...} /threads:{1,2,...}
--no-threads is a name copied from gold.
gold has --no-thread, --thread-count and several other --thread-count-*.
There are needs to customize the number of threads (running several lld
processes concurrently or customizing the number of LTO threads).
Having a single --threads=N is a straightforward replacement of gold's
--no-threads + --thread-count.
--no-threads is used rarely. So just delete --no-threads instead of
keeping it for compatibility for a while.
If --threads= is specified (ELF,wasm; COFF /threads: is similar),
--thinlto-jobs= defaults to --threads=,
otherwise all available hardware threads are used.
There is currently no way to override a --threads={1,2,...}. It is still
a debate whether we should use --threads=all.
Reviewed By: rnk, aganea
Differential Revision: https://reviews.llvm.org/D76885
2020-03-18 03:40:19 +08:00
|
|
|
# RUN: ld.lld --build-id=tree %t -o %t2 --threads=1
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=SHA1 %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-08-26 17:55:37 +08:00
|
|
|
# RUN: ld.lld --build-id=uuid %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=UUID %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-05-14 05:55:56 +08:00
|
|
|
# RUN: ld.lld --build-id=0x12345678 %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=HEX %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
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
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=NONE %s
|
2016-11-17 01:14:11 +08:00
|
|
|
|
2016-05-04 04:55:47 +08:00
|
|
|
# RUN: ld.lld --build-id=md5 --build-id=none %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=NONE %s
|
2017-05-24 05:16:48 +08:00
|
|
|
# RUN: ld.lld --build-id --build-id=none %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=NONE %s
|
2017-05-24 05:16:48 +08:00
|
|
|
# RUN: ld.lld --build-id=none --build-id %t -o %t2
|
2020-03-16 08:47:44 +08:00
|
|
|
# RUN: llvm-objdump -s %t2 | FileCheck --check-prefix=DEFAULT %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
|
|
|
|
|
2017-10-31 06:08:11 +08:00
|
|
|
# ALIGN: Name: .note.gnu.build-id
|
|
|
|
# ALIGN-NEXT: Type: SHT_NOTE
|
|
|
|
# ALIGN-NEXT: Flags [
|
|
|
|
# ALIGN-NEXT: SHF_ALLOC
|
|
|
|
# ALIGN-NEXT: ]
|
|
|
|
# ALIGN-NEXT: Address:
|
|
|
|
# ALIGN-NEXT: Offset: [[_:0x[0-9A-Z]*(0|4|8|C)$]]
|
|
|
|
# ALIGN-NEXT: Size:
|
|
|
|
# ALIGN-NEXT: Link:
|
|
|
|
# ALIGN-NEXT: Info:
|
|
|
|
# ALIGN-NEXT: AddressAlignment: 4
|
|
|
|
|
2016-11-01 17:49:24 +08:00
|
|
|
# DEFAULT: Contents of section .note.test:
|
2016-04-08 06:49:21 +08:00
|
|
|
# DEFAULT: Contents of section .note.gnu.build-id:
|
|
|
|
# DEFAULT-NEXT: 04000000 08000000 03000000 474e5500 ............GNU.
|
2019-09-16 15:05:34 +08:00
|
|
|
# DEFAULT-NEXT: 7e8ddeff 3ed41fa3
|
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.
|
2019-09-16 15:05:34 +08:00
|
|
|
# MD5-NEXT: 7b00fd9e 054ceb4b 06f64d0e 482cb476
|
2016-04-08 06:49:21 +08:00
|
|
|
|
2016-04-08 07:51:56 +08:00
|
|
|
# SHA1: Contents of section .note.gnu.build-id:
|
|
|
|
# SHA1-NEXT: 04000000 14000000 03000000 474e5500 ............GNU.
|
2019-09-16 15:05:34 +08:00
|
|
|
# SHA1-NEXT: 221a99da dd1d2bf3 05e48a91 dde8a0cb
|
2016-04-08 07:51:56 +08:00
|
|
|
|
2016-08-26 17:55:37 +08:00
|
|
|
# UUID: Contents of section .note.gnu.build-id:
|
|
|
|
# UUID-NEXT: 04000000 10000000 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:
|
2022-01-17 14:36:22 +08:00
|
|
|
|
|
|
|
# RUN: ld.lld --build-id=sha1 -z separate-loadable-segments %t -o %t2
|
|
|
|
# RUN: llvm-readelf -x .note.gnu.build-id %t2 | FileCheck --check-prefix=SEPARATE %s
|
|
|
|
|
|
|
|
# SEPARATE: Hex dump of section '.note.gnu.build-id':
|
|
|
|
# SEPARATE-NEXT: 0x00200198 04000000 14000000 03000000 474e5500
|
|
|
|
# SEPARATE-NEXT: 0x002001a8 96820adf d90d5470 0a0c32ff a88c4017
|
|
|
|
|
|
|
|
# RUN: ld.lld --build-id=sha1 --no-rosegment %t -o %t2
|
|
|
|
# RUN: llvm-readelf -x .note.gnu.build-id %t2 | FileCheck --check-prefix=NORO %s
|
|
|
|
|
|
|
|
# NORO: Hex dump of section '.note.gnu.build-id':
|
|
|
|
# NORO-NEXT: 0x00200160 04000000 14000000 03000000 474e5500
|
|
|
|
# NORO-NEXT: 0x00200170 cf6d7b3a 0b3297c3 5b47c079 ce048349
|