[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/

Bill Wendling isanbard at gmail.com
Wed Jun 30 11:47:45 PDT 2010


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"?
> 
> 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.
> 
I view these linkages as being like their non-"linker linkage" counterparts, but that the linker will remove them from the final linked image. So, "linker_private" is "private" but the linker will remove it from the final linked image and so on. "linker_private_weak" has no non-"linker linkage" counterpart, but its semantics are a natural progression maybe?

-bw





More information about the llvm-commits mailing list