maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity

[gnu-objc] Make selector order deterministic. 

Summary:
This probably fixes PR35277, though there may be other sources of
nondeterminism (this was the only case of iterating over a DenseMap).

It's difficult to provide a test case for this, because it shows up only
on systems with ASLR enabled.

Reviewers: rjmccall

Reviewed By: rjmccall

Subscribers: bmwiedemann, mgrang, cfe-commits

Differential Revision: https://reviews.llvm.org/D50559

llvm-svn: 339668
This commit is contained in:
David Chisnall 2018-08-14 10:05:25 +00:00
parent 060a789c84
commit c66d480bce
2 changed files with 23 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
clang/lib/CodeGen/CGObjCGNU.cpp
View File

@ -3541,12 +3541,16 @@ llvm::Function *CGObjCGNU::ModuleInitFunction() {
ConstantInitBuilder builder(CGM);
auto selectors = builder.beginArray(selStructTy);
auto &table = SelectorTable; // MSVC workaround
for (auto &entry : table) {
std::vector<Selector> allSelectors;
for (auto &entry : table)
allSelectors.push_back(entry.first);
llvm::sort(allSelectors.begin(), allSelectors.end());
std::string selNameStr = entry.first.getAsString();
for (auto &untypedSel : allSelectors) {
std::string selNameStr = untypedSel.getAsString();
llvm::Constant *selName = ExportUniqueString(selNameStr, ".objc_sel_name");
for (TypedSelector &sel : entry.second) {
for (TypedSelector &sel : table[untypedSel]) {
llvm::Constant *selectorTypeEncoding = NULLPtr;
if (!sel.first.empty())
selectorTypeEncoding =

16
clang/test/CodeGenObjC/gnu-deterministic-selectors.m Normal file
View File

@ -0,0 +1,16 @@
// RUN: %clang_cc1 -triple x86_64-unknown-freebsd -fobjc-runtime=gnustep-1.5 %s -emit-llvm -o - | FileCheck %s
// RUN: %clang_cc1 -triple x86_64-unknown-freebsd -fobjc-runtime=gcc %s -emit-llvm -o - | FileCheck %s
// Check that these selectors are emitted in alphabetical order.
// The order doesn't actually matter, only that it doesn't vary across runs.
// Clang sorts them when targeting a GCC-like ABI to guarantee determinism.
// CHECK: @.objc_selector_list = internal global [6 x { i8*, i8* }] [{ i8*, i8* } { i8* getelementptr inbounds ([2 x i8], [2 x i8]* @.objc_sel_namea, i64 0, i64 0), i8* null }, { i8*, i8* } { i8* getelementptr inbounds ([2 x i8], [2 x i8]* @.objc_sel_nameg, i64 0, i64 0), i8* null }, { i8*, i8* } { i8* getelementptr inbounds ([2 x i8], [2 x i8]* @.objc_sel_namej, i64 0, i64 0), i8* null }, { i8*, i8* } { i8* getelementptr inbounds ([2 x i8], [2 x i8]* @.objc_sel_namel, i64 0, i64 0), i8* null }, { i8*, i8* } { i8* getelementptr inbounds ([2 x i8], [2 x i8]* @.objc_sel_namez, i64 0, i64 0), i8* null }, { i8*, i8* } zeroinitializer], align 8
void f() {
SEL a = @selector(z);
SEL b = @selector(a);
SEL c = @selector(g);
SEL d = @selector(l);
SEL e = @selector(j);
}