[cfe-dev] clang trunk: extern "C"/static problem

[Richard Smith]

On Thu, Mar 14, 2013 at 10:00 AM, John McCall <rjmccall at apple.com> wrote:

> On Mar 14, 2013, at 8:14 AM, "Richtarsky, Martin" <
> martin.richtarsky at sap.com> wrote:
> >> -----Original Message-----
> >> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
> >> Sent: Donnerstag, 14. März 2013 15:42
> >> To: Richtarsky, Martin
> >> Cc: cfe-dev at cs.uiuc.edu Developers; John McCall; Richard Smith
> >> Subject: Re: [cfe-dev] clang trunk: extern "C"/static problem
> >>
> >> On 14 March 2013 09:34, Richtarsky, Martin <martin.richtarsky at sap.com>
> wrote:
> >>> Hi,
> >>>
> >>> it seems there is a bug in current trunk with regards to the symbols
> that
> >> are generated. At least clang 3.1, gcc 4.3.4 and gcc 4.8 behave
> differently
> >> here.
> >>>
> >>> test.cpp:
> >>>
> >>> extern "C"
> >>> {
> >>>
> >>> static void __attribute__((__used__)) func(char *a, char b)
> >>> {
> >>> }
> >>>
> >>> }
> >>>
> >>> clang++ test.cpp
> >>>
> >>> nm -C test*.o shows these generated symbols for the different
> compilers:
> >>>
> >>> test_clang31.o:
> >>> 0000000000000000 t func
> >>>
> >>> test_clang33.o:
> >>> 0000000000000000 t func(char*, char)
> >>>
> >>> test_gcc43.o:
> >>>                 U __gxx_personality_v0
> >>> 0000000000000000 t func
> >>>
> >>> test_gcc48.o:
> >>> 0000000000000000 t func
> >>>
> >>>
> >>> It looks like the static in conjunction with the extern "C" is causing
> a
> >> problem here. Should I file a bug?
> >>
> >> The c++ standard
> >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf)
> >> says
> >>
> >> ------------------
> >> All function types, function names with external linkage, and variable
> >> names with external linkage have a language linkage.
> >> ------------------
> >>
> >> Since static functions have internal linkage, they don't have a
> >> language linkage. That is, the extern "C" doesn't apply.
> >>
> >> This was recently implemented in clang, and there was some discussion
> >> about maybe trying to change the standard instead. What problems is
> >> this causing?
> >
> > Hi Rafael,
> >
> > in this case the affected function is called from another function which
> is implemented in inline assembler, within the extern "C" scope.
>
> 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.
>

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.


> 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.
>
> John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130314/8f103ae3/attachment.html>