| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
still failing.
llvm-svn: 360363
|
| |
|
|
|
|
| |
failing.
llvm-svn: 360361
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
private symbols in the __DATA segment internal.
This prevents the linker from removing the symbol names. Keeping the
symbols visible enables tools to collect various information about the
symbols, for example, tools that discover whether or not a symbol gets
dirtied.
rdar://problem/48887111
Differential Revision: https://reviews.llvm.org/D61454
llvm-svn: 360359
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
metadata and protocol list
The leading 'l' tells ld64 to remove the symbol name, which can make
debugging difficult.
rdar://problem/47256637
Differential Revision: https://reviews.llvm.org/D59234
llvm-svn: 356156
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
expression
Clang emits invalid protocol metadata when a @protocol expression is used with a
forward-declared protocol. The protocol metadata is missing protocol conformance
list of the protocol since we don't have access to the definition of it in the
compiled translation unit. The linker then might end up picking the invalid
metadata when linking which will lead to incorrect runtime protocol conformance
checks.
This commit makes sure that Clang fails to compile code that uses a @protocol
expression with a forward-declared protocol. This ensures that Clang does not
emit invalid protocol metadata. I added an extra assert in CodeGen to ensure
that this kind of issue won't happen in other places.
rdar://32787811
Differential Revision: https://reviews.llvm.org/D49462
llvm-svn: 340102
|
| |
|
|
|
|
|
|
|
| |
These symbols are supposed to be preserved even by the linker. Use the
`llvm.used` to ensure that the symbols are not removed by DCE in the
linker. This should be a no-op change on MachO since the symbols are
annotated as `no_dead_strip`.
llvm-svn: 323247
|
| |
|
|
|
|
|
| |
Use CHECK-SAME directives to simplify the test conditions a bit. This
makes it easier to see what is being checked. NFC.
llvm-svn: 323230
|
| |
|
|
|
|
|
| |
details in http://reviews.llvm.org/D9483
goes with llvm checkin r237150
llvm-svn: 237151
|
| |
|
|
|
|
| |
Simply marking the symbol private conveys the desire to hide them to LLVM.
llvm-svn: 221451
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.
The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.
llvm-svn: 203172
|
| |
|
|
| |
llvm-svn: 203170
|
| |
|
|
|
|
|
|
| |
This reverts commit r203059.
Revert while we discuss what does it mean to be private and weak.
llvm-svn: 203141
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch changes the remaining GlobalVariables using "\01L" and
"\01l" prefixes to use private linkage. What is strange about them is
that they currently use WeakAnyLinkage. There is no comment stating
why and that is really odd since the symbols are completely hidden, so
it doesn't make sense for them to be weak.
Clang revisions like r63329, r63408, r63770, r65761 set the linkage to
weak, but don't say why. I suspect they were just copying llvm-gcc.
In llvm-gcc I found r58599 and r56322 that set DECL_WEAK, but they
were just syncing from the apple gcc. I am not exactly sure what that
means, since the last commit to
svn://gcc.gnu.org/svn/gcc/branches/apple was in 2006, 2 years earlier.
In summary, I have no idea why weak linkage was being used :-(
To quote John McCall, "Let’s try without it and see" :-)
llvm-svn: 203059
|
|
|
for metadata symbols for forward referenced protocols which
are never defined. // rdar://16203115
llvm-svn: 202761
|
