clang

Commit Graph

Author	SHA1	Message	Date
Rafael Espindola	51cd00abaf	Use private linkage for utf-16 objc strings too. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199709 91177308-0d34-0410-b5e6-96231b3b80d8	2014-01-21 02:57:56 +00:00
Rafael Espindola	68aa3e1054	Give explicit sections for string constants used in NSStrings. Without them they can be merged with non unnamed_addr constants during LTO. The resulting constant is not unnamed_addr and goes in a different section, which causes ld64 to crash. A testcase that would crash before: * file1.mm: void g(id notification) { [notification valueForKey:@"name"]; } * file2.cpp: extern const char js_name_str[] = "name"; * file3.cpp extern bool JS_GetProperty(const char *name); extern const char js_name_str[]; bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); } run clang file1.mm -o file1.o -c -w -emit-llvm clang file2.cpp -o file2.o -c -w -emit-llvm clang file3.cpp -o file3.o -c -w ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup. git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199688 91177308-0d34-0410-b5e6-96231b3b80d8	2014-01-20 20:33:18 +00:00
Bill Wendling	84392d0edc	The UTF16 string referenced by a CFString should go into the __TEXT,__ustring section. A 'normal' string will go into the __TEXT,__const section, but this isn't good for UTF16 strings. The __ustring section allows for coalescing, among other niceties (such as allowing the linker to easily split up strings). Instead of outputting the UTF16 string as a series of bytes, output it as a series of shorts. The back-end will then nicely place the UTF16 string into the correct section, because it's a mensch. <rdar://problem/10655949> git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153710 91177308-0d34-0410-b5e6-96231b3b80d8	2012-03-30 00:26:17 +00:00

Author

SHA1

Message

Date

Rafael Espindola

51cd00abaf

Use private linkage for utf-16 objc strings too.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199709 91177308-0d34-0410-b5e6-96231b3b80d8

2014-01-21 02:57:56 +00:00

Rafael Espindola

68aa3e1054

Give explicit sections for string constants used in NSStrings.

Without them they can be merged with non unnamed_addr constants during LTO.
The resulting constant is not unnamed_addr and goes in a different section,
which causes ld64 to crash.

A testcase that would crash before:

* file1.mm:
void g(id notification) {
  [notification valueForKey:@"name"];
}

* file2.cpp:
extern const char js_name_str[] = "name";

* file3.cpp
extern bool JS_GetProperty(const char *name);
extern const char js_name_str[];
bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); }

run

clang file1.mm  -o file1.o -c -w -emit-llvm
clang file2.cpp -o file2.o -c -w -emit-llvm
clang file3.cpp -o file3.o -c -w

ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199688 91177308-0d34-0410-b5e6-96231b3b80d8

2014-01-20 20:33:18 +00:00

Bill Wendling

84392d0edc

The UTF16 string referenced by a CFString should go into the __TEXT,__ustring

section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).

Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153710 91177308-0d34-0410-b5e6-96231b3b80d8

2012-03-30 00:26:17 +00:00

3 Commits