[llvm-commits] [llvm] r107205 - in /llvm/trunk: bindings/ada/llvm/ docs/ include/llvm-c/ include/llvm/ include/llvm/CodeGen/ include/llvm/MC/ include/llvm/Target/ lib/AsmParser/ lib/Bitcode/Reader/ lib/Bitcode/Writer/ lib/CodeGen/ lib/CodeGen/AsmPrinter/ lib/Linker/ lib/MC/ lib/Target/ lib/Target/CppBackend/ lib/Target/XCore/AsmPrinter/ lib/Transforms/IPO/ lib/VMCore/ tools/llvm-nm/

[Chris Lattner]

On Jun 30, 2010, at 11:36 AM, Dan Gohman wrote:

> 
> On Jun 30, 2010, at 8:24 AM, Chris Lattner wrote:
> 
>> 
>> On Jun 29, 2010, at 3:33 PM, Bill Wendling wrote:
>> 
>>> On Jun 29, 2010, at 2:56 PM, Chris Lattner wrote:
>>> 
>>>> On Jun 29, 2010, at 2:24 PM, Bill Wendling wrote:
>>>> 
>>>>> Author: void
>>>>> Date: Tue Jun 29 16:24:00 2010
>>>>> New Revision: 107205
>>>>> 
>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=107205&view=rev
>>>>> Log:
>>>>> Introducing the "linker_weak" linkage type. This will be used for Objective-C
>>>>> metadata types which should be marked as "weak", but which the linker will
>>>>> remove upon final linkage.
>>>> 
>>>> Hi Bill,
>>>> 
>>>> This would have been good to talk about before you implemented it.  The name linker_weak doesn't seem very descriptive.  How about linker_private_weak or something like that?
>>>> 
>>> I thought about that, but they aren't private from what I can tell. They're marked as ".globl" and ".weak_definition".
>> 
>> They are "as private" as other "l" labels, right?  Those are visible across translation units too.  We call it "linker private" so calling this "linker_private_weak" seems reasonable.  Any other suggestions?
> 
> How about "objc_linker_private_weak"?

No, it's not objc specific, objc metadata just happens to use it.

> Unless someone here can really spell out what these things really
> mean, without mentioning assembler directives, without mentioning
> special label naming conventions, without describing it in terms of
> what gcc does for Objective C, and without citing "this is what the
> Objective C people say we need", and without excluding any magical
> semantics, it would be best to avoid confusion.

This is easy to do, Bill just needs to do it.  I completely agree that it is imperative that this happen!

-Chris