RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-10-29 23:12:55 +01:00
Code Issues Projects Releases Wiki Activity
de7985179f
llvm-mirror/test/MC/COFF/feat00.s

15 lines
378 B
ArmAsm
Raw Normal View History

COFF: Ensure that objects produced by LLVM link with /safeseh Summary: We indicate that the object files are safe by emitting a @feat.00 absolute address symbol. The address is presumably interpreted as a bitfield of features that the compiler would like to enable. Bit 0 is documented in the PE COFF spec to opt in to "registered SEH", which is what /safeseh enables. LLVM's object files are safe by default because LLVM doesn't know how to produce SEH handlers. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1691 llvm-svn: 190898
2013-09-18 01:18:05 +02:00
// RUN: llvm-mc -filetype=obj -triple i686-pc-win32 %s -o - | llvm-readobj -t | FileCheck %s
"@feat.00" = 123
Revert "COFF: Emit all MCSymbols rather than filtering out some of them" This reverts commit r190888, to fix PR17967. The original change wasn't the right way to get @feat.00 into the object file. The right fix is to make @feat.00 be a global symbol. llvm-svn: 195053
2013-11-19 00:08:12 +01:00
.globl @feat.00
COFF: Ensure that objects produced by LLVM link with /safeseh Summary: We indicate that the object files are safe by emitting a @feat.00 absolute address symbol. The address is presumably interpreted as a bitfield of features that the compiler would like to enable. Bit 0 is documented in the PE COFF spec to opt in to "registered SEH", which is what /safeseh enables. LLVM's object files are safe by default because LLVM doesn't know how to produce SEH handlers. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1691 llvm-svn: 190898
2013-09-18 01:18:05 +02:00
// CHECK: Symbol {
// CHECK: Name: @feat.00
// CHECK: Value: 123
Object/COFF: change data type of SymbolNumber from int16 to uint16. Microsoft PE/COFF Spec clearly states that the field is of signed interger type. However, in reality, it's unsigned. If cl.exe needs to create a large number of sections for COMDAT sections, it will just create more than 32768 sections. Handling large section number as negative number is not correct. I think this is a spec bug. Differential Revision: http://llvm-reviews.chandlerc.com/D3088 llvm-svn: 203986
2014-03-15 01:04:08 +01:00
// CHECK: Section: (65535)
COFF: Ensure that objects produced by LLVM link with /safeseh Summary: We indicate that the object files are safe by emitting a @feat.00 absolute address symbol. The address is presumably interpreted as a bitfield of features that the compiler would like to enable. Bit 0 is documented in the PE COFF spec to opt in to "registered SEH", which is what /safeseh enables. LLVM's object files are safe by default because LLVM doesn't know how to produce SEH handlers. Reviewers: Bigcheese CC: llvm-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1691 llvm-svn: 190898
2013-09-18 01:18:05 +02:00
// CHECK: BaseType: Null (0x0)
// CHECK: ComplexType: Null (0x0)
// CHECK: StorageClass: External (0x2)
// CHECK: AuxSymbolCount: 0
// CHECK: }
Reference in New Issue Copy Permalink