[llvm-bugs] [Bug 46503] New: [thinlto] -x86-asm-syntax should not affect module level inline asm parsing + link errors

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=46503

            Bug ID: 46503
           Summary: [thinlto] -x86-asm-syntax should not affect module
                    level inline asm parsing + link errors
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org,
                    peter at pcc.me.uk

(This is the real problem I was trying to understand re: Bug 46502)


Reproducer:

$ cat /tmp/x.c
void foo() {}

asm(".globl bar      \n"
    "bar:            \n"
    "  xor %eax, %eax\n"
    "  ret           \n");

$ cat /tmp/y.c
extern void foo();
extern void bar();

int main() {
  foo();
  bar();
  return 0;
}

$ build.release/bin/clang-cl -flto=thin -m64 /c /tmp/x.c /tmp/y.c &&
build.release/bin/lld-link /out:a.exe x.obj y.obj /nodefaultlib:oldnames.lib
/nodefaultlib:libcmt.lib /entry:main
error: unknown token in expression
  xor %eax, %eax
      ^
error: unknown token in expression
  xor %eax, %eax
      ^
lld-link: error: undefined symbol: bar
>>> referenced by /tmp/y.c
>>>               y.obj



Note that the asm parsing error and link failure only happens during ThinLTO,
not during normal compilation.

The "unknown token in expression" error comes from clang-cl passing -mllvm
-x86-asm-syntax=intel. That's only supposed to affect the asm dialect used for
*writing*, not for *reading* assembly.

The regular inline asm parser gets this right and defaults to At&t dialect, but
the parser used in ModuleSymbolTable doesn't do this. I believe this is the
right fix:


diff --git a/llvm/lib/Object/ModuleSymbolTable.cpp
b/llvm/lib/Object/ModuleSymbolTable.cpp
index 45bcf748189..b2b09cf27df 100644
--- a/llvm/lib/Object/ModuleSymbolTable.cpp
+++ b/llvm/lib/Object/ModuleSymbolTable.cpp
@@ -23,6 +23,7 @@
 #include "llvm/IR/GlobalAlias.h"
 #include "llvm/IR/GlobalValue.h"
 #include "llvm/IR/GlobalVariable.h"
+#include "llvm/IR/InlineAsm.h"
 #include "llvm/IR/Module.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/MCContext.h"
@@ -116,6 +117,10 @@ initializeRecordStreamer(const Module &M,
   if (!TAP)
     return;

+  // Module-level inline asm is assumed to use AT&T syntax (see
+  // AsmPrinter::doInitialization()).
+  Parser->setAssemblerDialect(InlineAsm::AD_ATT);
+
   Parser->setTargetParser(*TAP);
   if (Parser->Run(false))
     return;



However, I can't see exactly what this changes on the object file level (making
it hard to write a test) and also don't fully understand the link failure,
because even when the link fails, the symbol shows up as defined in the symbol
table:

$ build.release/bin/llvm-nm x.obj
---------------- T bar
---------------- T foo

$ build.release/bin/llvm-nm y.obj
                 U bar
                 U foo
---------------- T main

I assume there's something else involved in the symbol resolution.

Peter, does this make sense, and what am I missing?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200629/cefdabed/attachment-0001.html>