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.

79 lines
1.9 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
# RUN: lld -flavor darwinnew -o %t %t.o
# RUN: llvm-readobj --section-headers --macho-segment %t | FileCheck %s
[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 that __bss takes up zero file size, is at file offset zero, and
## appears at the end of its segment.
[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
# 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 .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: Size: 0x8
[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] 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: Index: 3
# CHECK-NEXT: Name: __thread_bss
# CHECK-NEXT: Segment: __DATA
# CHECK-NEXT: Address: 0x100001010
# 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
[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 .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: vmsize: 0x14
[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] 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: filesize: 8
[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
.zero 4
[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
.zero 4
[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