maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/cfstring-elf-sections-x86_64.c

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

24 lines
1015 B
C
Raw Normal View History

Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`" Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately 1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF). This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 343038
2018-09-26 06:27:40 +08:00
// REQUIRES: x86-registered-target
// RUN: %clang_cc1 -triple x86_64-elf -S %s -o - | FileCheck %s -check-prefix CHECK-ELF-DATA-SECTION
typedef struct __CFString *CFStringRef;
const CFStringRef one = (CFStringRef)__builtin___CFStringMakeConstantString("one");
const CFStringRef two = (CFStringRef)__builtin___CFStringMakeConstantString("\xef\xbf\xbd\x74\xef\xbf\xbd\x77\xef\xbf\xbd\x6f");
// CHECK-ELF-DATA-SECTION: .type .L.str,@object
[MC][ELF] Put explicit section name symbols into entry size compatible sections Ensure that symbols explicitly* assigned a section name are placed into a section with a compatible entry size. This is done by creating multiple sections with the same name** if incompatible symbols are explicitly given the name of an incompatible section, whilst: - Avoiding using uniqued sections where possible (for readability and to maximize compatibly with assemblers). - Creating as few SHF_MERGE sections as possible (for efficiency). Given that each symbol is assigned to a section in a single pass, we must decide which section each symbol is assigned to without seeing the properties of all symbols. A stable and easy to understand assignment is desirable. The following rules facilitate this: The "generic" section for a given section name will be mergeable if the name is a mergeable "default" section name (such as .debug_str), a mergeable "implicit" section name (such as .rodata.str2.2), or MC has already created a mergeable "generic" section for the given section name (e.g. in response to a section directive in inline assembly). Otherwise, the "generic" section for a given name is non-mergeable; and, non-mergeable symbols are assigned to the "generic" section, while mergeable symbols are assigned to uniqued sections. Terminology: "default" sections are those always created by MC initially, e.g. .text or .debug_str. "implicit" sections are those created normally by MC in response to the symbols that it encounters, i.e. in the absence of an explicit section name assignment on the symbol, e.g. a function foo might be placed into a .text.foo section. "generic" sections are those that are referred to when a unique section ID is not supplied, e.g. if there are multiple unique .bob sections then ".quad .bob" will reference the generic .bob section. Typically, the generic section is just the first section of a given name to be created. Default sections are always generic. * Typically, section names might be explicitly assigned in source code using a language extension e.g. a section attribute: _attribute_ ((section ("section-name"))) - https://clang.llvm.org/docs/AttributeReference.html ** I refer to such sections as unique/uniqued sections. In assembly the ", unique," assembly syntax is used to express such sections. Fixes https://bugs.llvm.org/show_bug.cgi?id=43457. See https://reviews.llvm.org/D68101 for previous discussions leading to this patch. Some minor fixes were required to LLVM's tests, for tests had been using the old behavior - which allowed for explicitly assigning globals with incompatible entry sizes to a section. This fix relies on the ",unique ," assembly feature. This feature is not available until bintuils version 2.35 (https://sourceware.org/bugzilla/show_bug.cgi?id=25380). If the integrated assembler is not being used then we avoid using this feature for compatibility and instead try to place mergeable symbols into non-mergeable sections or issue an error otherwise. Differential Revision: https://reviews.llvm.org/D72194
2020-04-16 18:45:31 +08:00
// CHECK-ELF-DATA-SECTION: .section .rodata,"aMS",@progbits,1,unique,1
Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`" Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately 1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF). This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 343038
2018-09-26 06:27:40 +08:00
// CHECK-ELF-DATA-SECTION: .L.str:
// CHECK-ELF-DATA-SECTION: .asciz "one"
// CHECK-ELF-DATA-SECTION: .type .L.str.1,@object
[MC][ELF] Put explicit section name symbols into entry size compatible sections Ensure that symbols explicitly* assigned a section name are placed into a section with a compatible entry size. This is done by creating multiple sections with the same name** if incompatible symbols are explicitly given the name of an incompatible section, whilst: - Avoiding using uniqued sections where possible (for readability and to maximize compatibly with assemblers). - Creating as few SHF_MERGE sections as possible (for efficiency). Given that each symbol is assigned to a section in a single pass, we must decide which section each symbol is assigned to without seeing the properties of all symbols. A stable and easy to understand assignment is desirable. The following rules facilitate this: The "generic" section for a given section name will be mergeable if the name is a mergeable "default" section name (such as .debug_str), a mergeable "implicit" section name (such as .rodata.str2.2), or MC has already created a mergeable "generic" section for the given section name (e.g. in response to a section directive in inline assembly). Otherwise, the "generic" section for a given name is non-mergeable; and, non-mergeable symbols are assigned to the "generic" section, while mergeable symbols are assigned to uniqued sections. Terminology: "default" sections are those always created by MC initially, e.g. .text or .debug_str. "implicit" sections are those created normally by MC in response to the symbols that it encounters, i.e. in the absence of an explicit section name assignment on the symbol, e.g. a function foo might be placed into a .text.foo section. "generic" sections are those that are referred to when a unique section ID is not supplied, e.g. if there are multiple unique .bob sections then ".quad .bob" will reference the generic .bob section. Typically, the generic section is just the first section of a given name to be created. Default sections are always generic. * Typically, section names might be explicitly assigned in source code using a language extension e.g. a section attribute: _attribute_ ((section ("section-name"))) - https://clang.llvm.org/docs/AttributeReference.html ** I refer to such sections as unique/uniqued sections. In assembly the ", unique," assembly syntax is used to express such sections. Fixes https://bugs.llvm.org/show_bug.cgi?id=43457. See https://reviews.llvm.org/D68101 for previous discussions leading to this patch. Some minor fixes were required to LLVM's tests, for tests had been using the old behavior - which allowed for explicitly assigning globals with incompatible entry sizes to a section. This fix relies on the ",unique ," assembly feature. This feature is not available until bintuils version 2.35 (https://sourceware.org/bugzilla/show_bug.cgi?id=25380). If the integrated assembler is not being used then we avoid using this feature for compatibility and instead try to place mergeable symbols into non-mergeable sections or issue an error otherwise. Differential Revision: https://reviews.llvm.org/D72194
2020-04-16 18:45:31 +08:00
// CHECK-ELF-DATA-SECTION: .section .rodata,"aMS",@progbits,2,unique,2
Reland "[Clang][CodeGen][ObjC]: Fix CoreFoundation on ELF with `-fconstant-cfstrings`" Relanding rL342883 with more fragmented tests to test ELF-specific section emission separately from broad-scope CFString tests. Now this tests the following separately 1). CoreFoundation builds and linkage for ELF while building it. 2). CFString ELF section emission outside CF in assembly output. 3). Broad scope `cfstring3.c` tests which cover all object formats at bitcode level and assembly level (including ELF). This fixes non-bridged CoreFoundation builds on ELF targets that use -fconstant-cfstrings. The original changes from differential for a similar patch to PE/COFF (https://reviews.llvm.org/D44491) did not check for an edge case where the global could be a constant which surfaced as an issue when building for ELF because of different linkage semantics. This patch addresses several issues with crashes related to CF builds on ELF as well as improves data layout by ensuring string literals that back the actual CFConstStrings end up in .rodata in line with Mach-O. Change itself tested with CoreFoundation on Linux x86_64 but should be valid for BSD-like systems as well that use ELF as the native object format. Differential Revision: https://reviews.llvm.org/D52344 llvm-svn: 343038
2018-09-26 06:27:40 +08:00
// CHECK-ELF-DATA-SECTION: .L.str.1:
// CHECK-ELF-DATA-SECTION: .short 65533
// CHECK-ELF-DATA-SECTION: .short 116
// CHECK-ELF-DATA-SECTION: .short 65533
// CHECK-ELF-DATA-SECTION: .short 119
// CHECK-ELF-DATA-SECTION: .short 65533
// CHECK-ELF-DATA-SECTION: .short 111
// CHECK-ELF-DATA-SECTION: .short 0