On Thu, Mar 14, 2013 at 6:27 PM, 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 style="word-wrap:break-word"><div><div><div>On Mar 14, 2013, at 5:59 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>> wrote:</div></div><blockquote type="cite">
<div>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><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div><div>On Mar 14, 2013, at 8:14 AM, "Richtarsky, Martin" <<a href="mailto:martin.richtarsky@sap.com" target="_blank">martin.richtarsky@sap.com</a>> wrote:<br></div><div>> 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></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>
</div></blockquote><div><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.</div></div></div></blockquote><div><br></div><div>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.</div>
</div></div></blockquote><div><br></div><div>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:</div>
<div><br></div><div><a href="http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130218/074660.html">http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20130218/074660.html</a></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><blockquote type="cite"><div class="gmail_quote"><div>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></blockquote><div><br></div></div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div> 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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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?</div>
</div>