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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

126 lines
3.1 KiB
ArmAsm
Raw Normal View History

[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# REQUIRES: x86
# RUN: llvm-mc -filetype=obj -triple=x86_64-apple-darwin %s -o %t.o
[lld-macho] Always include custom syslibroot when running tests This greatly reduces the amount of boilerplate in our tests. Reviewed By: #lld-macho, compnerd Differential Revision: https://reviews.llvm.org/D87960
2020-09-19 12:40:12 +08:00
# RUN: %lld -o %t %t.o
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# RUN: llvm-readobj --section-headers --macho-segment %t | FileCheck %s
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
## Check that __bss takes up zero file size, is at file offset zero, and appears
## at the end of its segment. Also check that __tbss is placed immediately
## before it.
## Zerofill sections in other segments (i.e. not __DATA) should also be placed
## at the end.
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
[lld-macho] Make sure ZeroFill sections are at the end of their segments Summary: ld64 does this, and references an internal rdar:// number as an explanation. No idea what that rdar issue is, but in practice, it seems that not putting a BSS section at the end can cause subsequent sections in the same segment to be overwritten with zeroes. Reviewers: #lld-macho Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81888
2020-06-16 06:00:27 +08:00
# CHECK: Index: 1
# CHECK-NEXT: Name: __data
# CHECK-NEXT: Segment: __DATA
# CHECK-NEXT: Address:
# CHECK-NEXT: Size: 0x8
# CHECK-NEXT: Offset: 4096
# CHECK-NEXT: Alignment: 0
# CHECK-NEXT: RelocationOffset: 0x0
# CHECK-NEXT: RelocationCount: 0
# CHECK-NEXT: Type: Regular (0x0)
# CHECK-NEXT: Attributes [ (0x0)
# CHECK-NEXT: ]
# CHECK-NEXT: Reserved1: 0x0
# CHECK-NEXT: Reserved2: 0x0
# CHECK-NEXT: Reserved3: 0x0
# CHECK: Index: 2
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
# CHECK-NEXT: Name: __thread_bss
# CHECK-NEXT: Segment: __DATA
# CHECK-NEXT: Address:
# CHECK-NEXT: Size: 0x4
# CHECK-NEXT: Offset: 0
# CHECK-NEXT: Alignment: 0
# CHECK-NEXT: RelocationOffset: 0x0
# CHECK-NEXT: RelocationCount: 0
# CHECK-NEXT: Type: ThreadLocalZerofill (0x12)
# CHECK-NEXT: Attributes [ (0x0)
# CHECK-NEXT: ]
# CHECK-NEXT: Reserved1: 0x0
# CHECK-NEXT: Reserved2: 0x0
# CHECK-NEXT: Reserved3: 0x0
# CHECK: Index: 3
[lld-macho] Make sure ZeroFill sections are at the end of their segments Summary: ld64 does this, and references an internal rdar:// number as an explanation. No idea what that rdar issue is, but in practice, it seems that not putting a BSS section at the end can cause subsequent sections in the same segment to be overwritten with zeroes. Reviewers: #lld-macho Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81888
2020-06-16 06:00:27 +08:00
# CHECK-NEXT: Name: __bss
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# CHECK-NEXT: Segment: __DATA
# CHECK-NEXT: Address:
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# CHECK-NEXT: Size: 0x10000
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# CHECK-NEXT: Offset: 0
# CHECK-NEXT: Alignment: 0
# CHECK-NEXT: RelocationOffset: 0x0
# CHECK-NEXT: RelocationCount: 0
# CHECK-NEXT: Type: ZeroFill (0x1)
# CHECK-NEXT: Attributes [ (0x0)
# CHECK-NEXT: ]
# CHECK-NEXT: Reserved1: 0x0
# CHECK-NEXT: Reserved2: 0x0
# CHECK-NEXT: Reserved3: 0x0
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
# CHECK: Index: 4
# CHECK-NEXT: Name: foo
# CHECK-NEXT: Segment: FOO
# CHECK-NEXT: Address:
# CHECK-NEXT: Size: 0x8
# CHECK-NEXT: Offset: 8192
# CHECK-NEXT: Alignment: 0
# CHECK-NEXT: RelocationOffset: 0x0
# CHECK-NEXT: RelocationCount: 0
# CHECK-NEXT: Type: Regular (0x0)
# CHECK-NEXT: Attributes [ (0x0)
# CHECK-NEXT: ]
# CHECK-NEXT: Reserved1: 0x0
# CHECK-NEXT: Reserved2: 0x0
# CHECK-NEXT: Reserved3: 0x0
# CHECK: Index: 5
# CHECK-NEXT: Name: bss
# CHECK-NEXT: Segment: FOO
# CHECK-NEXT: Address:
# CHECK-NEXT: Size: 0x8
[lld-macho] Ensure .tbss sections are also considered as ZeroFilled This diff makes the behavior in {D80859} and {D81888} apply to thread-local ZeroFill sections too. I realized this was necessary whie trying to implement thread-local variables. Reviewed By: #lld-macho, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D85079
2020-08-08 02:04:41 +08:00
# CHECK-NEXT: Offset: 0
# CHECK-NEXT: Alignment: 0
# CHECK-NEXT: RelocationOffset: 0x0
# CHECK-NEXT: RelocationCount: 0
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
# CHECK-NEXT: Type: ZeroFill (0x1)
[lld-macho] Ensure .tbss sections are also considered as ZeroFilled This diff makes the behavior in {D80859} and {D81888} apply to thread-local ZeroFill sections too. I realized this was necessary whie trying to implement thread-local variables. Reviewed By: #lld-macho, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D85079
2020-08-08 02:04:41 +08:00
# CHECK-NEXT: Attributes [ (0x0)
# CHECK-NEXT: ]
# CHECK-NEXT: Reserved1: 0x0
# CHECK-NEXT: Reserved2: 0x0
# CHECK-NEXT: Reserved3: 0x0
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# CHECK: Name: __DATA
# CHECK-NEXT: Size:
# CHECK-NEXT: vmaddr:
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# CHECK-NEXT: vmsize: 0x11000
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
# CHECK-NEXT: fileoff:
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# CHECK-NEXT: filesize: 4096
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
# CHECK: Name: FOO
# CHECK-NEXT: Size:
# CHECK-NEXT: vmaddr:
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# CHECK-NEXT: vmsize: 0x9000
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
# CHECK-NEXT: fileoff:
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
# CHECK-NEXT: filesize: 4096
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
[lld-macho] Ensure __bss sections we output have file offset of zero Summary: llvm-mc emits `__bss` sections with an offset of zero, but we weren't expecting that in our input, so we were copying non-zero data from the start of the file and putting it in `__bss`, with obviously undesirable runtime results. (It appears that the kernel will copy those nonzero bytes as long as the offset is nonzero, regardless of whether S_ZERO_FILL is set.) I debated on whether to make a special ZeroFillSection -- separate from a regular InputSection -- but it seemed like too much work for now. But I'm happy to refactor if anyone feels strongly about having it as a separate class. Depends on D80857. Reviewers: ruiu, pcc, MaskRay, smeenai, alexshap, gkm, Ktwu, christylee Reviewed By: smeenai Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D80859
2020-06-14 11:00:36 +08:00
.globl _main
.text
_main:
movq $0, %rax
retq
.bss
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
.zero 0x8000
[lld-macho] Make sure ZeroFill sections are at the end of their segments Summary: ld64 does this, and references an internal rdar:// number as an explanation. No idea what that rdar issue is, but in practice, it seems that not putting a BSS section at the end can cause subsequent sections in the same segment to be overwritten with zeroes. Reviewers: #lld-macho Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81888
2020-06-16 06:00:27 +08:00
[lld-macho] Ensure .tbss sections are also considered as ZeroFilled This diff makes the behavior in {D80859} and {D81888} apply to thread-local ZeroFill sections too. I realized this was necessary whie trying to implement thread-local variables. Reviewed By: #lld-macho, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D85079
2020-08-08 02:04:41 +08:00
.tbss _foo, 4
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
.zero 0x8000
[lld-macho] Ensure .tbss sections are also considered as ZeroFilled This diff makes the behavior in {D80859} and {D81888} apply to thread-local ZeroFill sections too. I realized this was necessary whie trying to implement thread-local variables. Reviewed By: #lld-macho, compnerd, MaskRay Differential Revision: https://reviews.llvm.org/D85079
2020-08-08 02:04:41 +08:00
[lld-macho] Make sure ZeroFill sections are at the end of their segments Summary: ld64 does this, and references an internal rdar:// number as an explanation. No idea what that rdar issue is, but in practice, it seems that not putting a BSS section at the end can cause subsequent sections in the same segment to be overwritten with zeroes. Reviewers: #lld-macho Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D81888
2020-06-16 06:00:27 +08:00
.data
.quad 0x1234
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
[lld-macho] Ensure segments are laid out contiguously codesign/libstuff checks that the `__LLVM` segment is directly before `__LINKEDIT` by checking that `fileOff + fileSize == next segment fileOff`. Previously, there would be gaps between the segments due to the fact that their fileOffs are page-aligned but their fileSizes aren't. In order to satisfy codesign, we page-align fileOff *before* calculating fileSize. (I don't think codesign checks for the relative ordering of other segments, so in theory we could do this just for `__LLVM`, but ld64 seems to do it for all segments.) Note that we *don't* round up the fileSize of the `__LINKEDIT` segment. Since it's the last segment, it doesn't need to worry about contiguity; in addition, codesign checks that the last (hidden) section in `__LINKEDIT` covers the last byte of the segment, so if we rounded up `__LINKEDIT`'s size we would have to do the same for its last section, which is a bother. While at it, I also addressed a FIXME in the linkedit-contiguity.s test to cover more `__LINKEDIT` sections. Reviewed By: #lld-macho, thakis, alexshap Differential Revision: https://reviews.llvm.org/D100848
2021-04-21 04:58:07 +08:00
.zerofill FOO,bss,_zero_foo,0x8000
[lld-macho] Fix TLV data initialization We were mishandling the case where both `__tbss` and `__thread_data` sections were present. TLVP relocations should be encoded as offsets from the start of `__thread_data`, even if the symbol is actually located in `__thread_bss`. Previously, we were writing the offset from the start of the containing section, which doesn't really make sense since there's no way `tlv_get_addr()` can know which section a given `tlv$init` symbol is in at runtime. In addition, this patch ensures that we place `__thread_data` immediately before `__thread_bss`. This is what ld64 does, likely for performance reasons. Zerofill sections must also be at the end of their segments; we were already doing this, but now we ensure that `__thread_bss` occurs before `__bss`, so that it's always possible to have it contiguous with `__thread_data`. Fixes llvm.org/PR48657. Reviewed By: #lld-macho, thakis Differential Revision: https://reviews.llvm.org/D94329
2021-01-09 07:47:40 +08:00
.section FOO,foo
.quad 123