maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lld/test/ELF/build-id.s

65 lines
2.2 KiB
ArmAsm
Raw Normal View History

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
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
# RUN: ld.lld --build-id %t -o %t2 -threads
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
# RUN: ld.lld --build-id %t -o %t2 -no-threads
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=DEFAULT %s
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
# RUN: ld.lld --build-id=md5 %t -o %t2 -threads
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=MD5 %s
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
# RUN: ld.lld --build-id=md5 %t -o %t2 -no-threads
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=MD5 %s
# RUN: ld.lld --build-id=sha1 %t -o %t2 -threads
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
# RUN: ld.lld --build-id=sha1 %t -o %t2 -no-threads
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
# RUN: ld.lld --build-id=tree %t -o %t2 -threads
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
# RUN: ld.lld --build-id=tree %t -o %t2 -no-threads
ELF: Add --build-id=sha1 option. llvm-svn: 265748
2016-04-08 07:51:56 +08:00
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=SHA1 %s
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
Implement support for --build-id=uuid switch Differential revision: https://reviews.llvm.org/D23349 llvm-svn: 279810
2016-08-26 17:55:37 +08:00
# RUN: ld.lld --build-id=uuid %t -o %t2
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=UUID %s
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
Support --build-id=0x<hexstring>. If you specify the option in the form of --build-id=0x<hexstring>, that hexstring is set as a build ID. We observed that the feature is actually in use in some builds, so we want this feature. llvm-svn: 269495
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
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
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
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# RUN: llvm-objdump -s %t2 | FileCheck -check-prefix=NONE %s
Define -build-id=tree as a synonym for -build-id=sha1. Our build-id is a tree hash anyway, so I'll define this as a synonym for sha1. GNU gold takes this parameter, so this is for compatibility with that. llvm-svn: 287119
2016-11-17 01:14:11 +08:00
Implement --build-id=none. Both bfd and gold have this. It allows disabling build-id when it is the default with by adding -Wl,--build-id=none no the clang command line. llvm-svn: 268435
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
Remove unnecessary trailing semicolons. Since this semicolon existed in an early test file, it has spread to many files. llvm-svn: 267659
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
ELF: Include the build ID section in the first page. At least Linux has the kernel configuration to include the first page of the executable into core files. We want build ID section to be included in core files to identify them. Here is the link to the description about the kernel configuration. https://github.com/torvalds/linux/blob/097f70b3c4d84ffccca15195bdfde3a37c0a7c0f/fs/Kconfig.binfmt#L46 llvm-svn: 263351
2016-03-13 09:54:48 +08:00
.section .note.test, "a", @note
.quad 42
Convert BuildIdSection to input section Differential revision: https://reviews.llvm.org/D25627 llvm-svn: 285682
2016-11-01 17:49:24 +08:00
# DEFAULT: Contents of section .note.test:
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# DEFAULT: Contents of section .note.gnu.build-id:
# DEFAULT-NEXT: 04000000 08000000 03000000 474e5500 ............GNU.
Stop propagating Entsize. Now that we combine multiple synthetic merge section into one output section there is no point in trying to propagate a value. llvm-svn: 294048
2017-02-04 05:29:51 +08:00
# DEFAULT-NEXT: fd36edb1 f6ff02af
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
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# MD5: Contents of section .note.gnu.build-id:
# MD5-NEXT: 04000000 10000000 03000000 474e5500 ............GNU.
Stop propagating Entsize. Now that we combine multiple synthetic merge section into one output section there is no point in trying to propagate a value. llvm-svn: 294048
2017-02-04 05:29:51 +08:00
# MD5-NEXT: fc
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
ELF: Add --build-id=sha1 option. llvm-svn: 265748
2016-04-08 07:51:56 +08:00
# SHA1: Contents of section .note.gnu.build-id:
# SHA1-NEXT: 04000000 14000000 03000000 474e5500 ............GNU.
Stop propagating Entsize. Now that we combine multiple synthetic merge section into one output section there is no point in trying to propagate a value. llvm-svn: 294048
2017-02-04 05:29:51 +08:00
# SHA1-NEXT: 55b1eedb 03b588e1 09987d1d e9a79be7
ELF: Add --build-id=sha1 option. llvm-svn: 265748
2016-04-08 07:51:56 +08:00
Implement support for --build-id=uuid switch Differential revision: https://reviews.llvm.org/D23349 llvm-svn: 279810
2016-08-26 17:55:37 +08:00
# UUID: Contents of section .note.gnu.build-id:
# UUID-NEXT: 04000000 10000000 03000000 474e5500 ............GNU.
Support --build-id=0x<hexstring>. If you specify the option in the form of --build-id=0x<hexstring>, that hexstring is set as a build ID. We observed that the feature is actually in use in some builds, so we want this feature. llvm-svn: 269495
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
ELF: Implement --build-id=md5. Previously, we supported only one hash function, FNV-1, so BuildIdSection directly handled hash computation. In this patch, I made BuildIdSection an abstract class and defined two subclasses, BuildIdFnv1 and BuildIdMd5. llvm-svn: 265737
2016-04-08 06:49:21 +08:00
# NONE-NOT: Contents of section .note.gnu.build-id: