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

[Richard Smith]

On Thu, Mar 14, 2013 at 6:27 PM, John McCall <rjmccall at apple.com> wrote:

> On Mar 14, 2013, at 5:59 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> 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:
>> > 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.
>
>
> I do not remember it coming up about inline assembly.  I remember it
> coming up about dynamic symbol lookups, and we were willing to wave our
> hands about those because there is very little code in the world that does
> this sort of symbol lookup into the enclosing process.  I am not willing to
> hand-wave away inline assembly.
>

Considering dynamic linking seems a bit strange; we were only ever talking
about internal linkage functions. Here's where I mentioned inline asm, and
asm labels, previously:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130218/074660.html

> 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.
>
>
> Conveniently enough, inline assembly usually can't be shared between
> platforms that do Pascal mangling and those that don't, because
> significantly different platforms usually have significantly different
> compilers and with significantly different inline assembly syntax.
>

Inconveniently, we have to cope with exactly that when we call into the
problematic symbols in llvm/lib/Target/X86/X86JITInfo.cpp (this is what the
message I quoted above was referring to). Search for calls to
LLVMX86CompilationCallback2, and note the ASMPREFIX hack.


>  What you're doing is making it more awkward to port inline assembly
> between compilers on the *same* platform by introducing a totally spurious
> hurdle, based on a line from the standard that's inconsistent with an
> overwhelmingly dominant existing practice.
>

I don't agree that g++ counts as "overwhelmingly dominant existing
practice", especially given that EDG does not follow g++ here in its
g++-compatible mode. This would not be the first g++ bug which people have
come to rely on, which we could support at the expense of being subtly
non-conforming, but choose not to. Plus, there is a simple, trivial fix to
the offending code which allows it to be accepted by us, g++, and EDG.

I think the right question is, is this a battle worth fighting? Is one
inconvenienced user enough that we should give up any hope of ever
conforming in this area?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130314/9235a2da/attachment.html>