On Thu, Mar 14, 2013 at 10:00 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Mar 14, 2013, at 8:14 AM, "Richtarsky, Martin" <<a href="mailto:martin.richtarsky@sap.com">martin.richtarsky@sap.com</a>> wrote:<br>
>> -----Original Message-----<br>
>> From: Rafael Espíndola [mailto:<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>]<br>
>> Sent: Donnerstag, 14. März 2013 15:42<br>
>> To: Richtarsky, Martin<br>
>> Cc: <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a> Developers; John McCall; Richard Smith<br>
>> Subject: Re: [cfe-dev] clang trunk: extern "C"/static problem<br>
>><br>
>> On 14 March 2013 09:34, Richtarsky, Martin <<a href="mailto:martin.richtarsky@sap.com">martin.richtarsky@sap.com</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> it seems there is a bug in current trunk with regards to the symbols that<br>
>> are generated. At least clang 3.1, gcc 4.3.4 and gcc 4.8 behave differently<br>
>> here.<br>
>>><br>
>>> test.cpp:<br>
>>><br>
>>> extern "C"<br>
>>> {<br>
>>><br>
>>> static void __attribute__((__used__)) func(char *a, char b)<br>
>>> {<br>
>>> }<br>
>>><br>
>>> }<br>
>>><br>
>>> clang++ test.cpp<br>
>>><br>
>>> nm -C test*.o shows these generated symbols for the different compilers:<br>
>>><br>
>>> test_clang31.o:<br>
>>> 0000000000000000 t func<br>
>>><br>
>>> test_clang33.o:<br>
>>> 0000000000000000 t func(char*, char)<br>
>>><br>
>>> test_gcc43.o:<br>
>>>                 U __gxx_personality_v0<br>
>>> 0000000000000000 t func<br>
>>><br>
>>> test_gcc48.o:<br>
>>> 0000000000000000 t func<br>
>>><br>
>>><br>
>>> It looks like the static in conjunction with the extern "C" is causing a<br>
>> problem here. Should I file a bug?<br>
>><br>
>> The c++ standard<br>
>> (<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf" target="_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf</a>)<br>
>> says<br>
>><br>
>> ------------------<br>
>> All function types, function names with external linkage, and variable<br>
>> names with external linkage have a language linkage.<br>
>> ------------------<br>
>><br>
>> Since static functions have internal linkage, they don't have a<br>
>> language linkage. That is, the extern "C" doesn't apply.<br>
>><br>
>> This was recently implemented in clang, and there was some discussion<br>
>> about maybe trying to change the standard instead. What problems is<br>
>> this causing?<br>
><br>
> Hi Rafael,<br>
><br>
> in this case the affected function is called from another function which is implemented in inline assembler, within the extern "C" scope.<br>
<br>
</div></div>Ah, you know, I can't believe we didn't think about inline assembly when we were enumerating potential places where this would bite us.  Too fixated on the JIT case, I suppose.<br></blockquote><div><br>
</div><div>We did think about it (although I'm not sure whether that made it to the list); in fact, this happened in some cases inside LLVM. Our conclusion was: if you want to use a function from inline asm, you should use an asm label on that function, otherwise it might get mangled unexpectedly. This is true independent of the static/extern "C" issue, due to some platforms prepending an underscore to symbol names, etc.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Personally, I think this basically kills the idea of treating these as overloadable, although I suppose you could try to hook it in to attribute((used)) if you *really* want to maintain that.<br>
<span class="HOEnZb"><font color="#888888"><br>
John.</font></span></blockquote></div><br>