Error parsing files with AST Matcher tool

Hi,

I have a simple file containing some Microsoft style inline asm. I can compile this file with -fms-extensions.

clang++ -fms-extensions -c test.cpp

No problem for this.

But when I write a simple AST Matcher tool (foo.out) to parse this file, I got errors.

./foo.out test.cpp – clang++ -fms-extensions -c test.cpp
test.cpp:19:3: error: MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
__asm {
^
test.cpp:28:3: error: MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
__asm mov a1, 2
^
2 errors generated.
Error while processing test.cpp.

There are also some other problems when parsing test.cpp. For example if I #include , I have to use – clang++ -I to identify the system header file path. I’m not sure what makes it different then the normal clang compile.

Best regards,
Han

Hi,

I have a simple file containing some Microsoft style inline asm. I can compile this file with -fms-extensions.

clang++ -fms-extensions -c test.cpp

No problem for this.

But when I write a simple AST Matcher tool (foo.out) to parse this file, I got errors.

./foo.out test.cpp – clang++ -fms-extensions -c test.cpp
test.cpp:19:3: error: MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
__asm {
^
test.cpp:28:3: error: MS-style inline assembly is not available: Unable to find target for this triple (no targets are registered)
__asm mov a1, 2
^
2 errors generated.
Error while processing test.cpp.

This seems to want an actual compilation triple to compile. Clang tools currently apparently don’t provide one. No idea why though.

There are also some other problems when parsing test.cpp. For example if I #include , I have to use – clang++ -I to identify the system header file path. I’m not sure what makes it different then the normal clang compile.

This definitely works on linux. I have no idea what the Windows system path logic is / should be in the clang driver. Adding Hans, who might have an idea…

Hi,

Thanks Manuel,

For the 1st issue, I’m working on mac trying to compile windows code.
For the 2nd issue, I’m working on mac.

Best regards,
Han

Hi,

I have a simple file containing some Microsoft style inline asm. I can
compile this file with -fms-extensions.

clang++ -fms-extensions -c test.cpp

No problem for this.

But when I write a simple AST Matcher tool (foo.out) to parse this file, I
got errors.

./foo.out test.cpp -- clang++ -fms-extensions -c test.cpp
test.cpp:19:3: error: MS-style inline assembly is not available: Unable to
find target for this triple (no targets are registered)
  __asm {
  ^
test.cpp:28:3: error: MS-style inline assembly is not available: Unable to
find target for this triple (no targets are registered)
  __asm mov a1, 2
  ^
2 errors generated.
Error while processing test.cpp.

This is most likely due to missing target initialization in your tool.
MS-style asm is special as it has to be parsed by clang, requiring
target support. GCC-style asm is parsed much later.

Solving it should be as simple as putting

llvm::InitializeAllTargets();
llvm::InitializeAllTargetMCs();
llvm::InitializeAllAsmPrinters();
llvm::InitializeAllAsmParsers();

in your main() function (or wherever the rest of clang is initialized).

There are also some other problems when parsing test.cpp. For example if I
#include <string>, I have to use -- clang++ -I<path-to-string> to identify
the system header file path. I'm not sure what makes it different then the
normal clang compile.

Mainline clang doesn't use headers from xcode.app. The easiest way
around that is just checking out libc++ into your LLVM tree.

- Ben

Thanks Ben,

The initialisations do work! Thank you very much.

I still have 1 question. What are the differences between these 2 forms?

  1. use clang to compile a file: clang++ -c test.cpp
  2. use clang tooling to parse a file ./foo.out test.cpp – clang++ -c test.cpp

Best regards,
Han

Sorry for hijacking this thread. I was looking into this issue few months ago and Reid suggested allowing tools to recover from partial AST in this case. I wanted to add a flag -fskip-inline-asm or something along those lines that would enable tools not to choke on code like this (some x86 windows system header files have inline asm). What do others think?

Adding Kim as I think he’s had to deal with this in IWYU.

I'm not sure what I think :slight_smile:

In IWYU, I added startup code to initalize only the X86 target info,
not all of them:
https://github.com/include-what-you-use/include-what-you-use/blob/master/iwyu.cc#L3817

I'm not sure if that's better in any measurable way.

I think your approach sounds useful, but it's not a great default mode
for tools since they occasionally *do* want to look inside MS inline
asm (we haven't bothered yet, but we could look for uses inside inline
asm, for example).

It'd be nice to be able to pass such a flag, though, if your tool
hasn't been built with X86 target info but you still want to process
code with MS inline assembly.

FWIW,
- Kim