[cfe-dev] clangd/libclang: how to emulate other compilers?
Milian Wolff via cfe-dev
cfe-dev at lists.llvm.org
Tue Apr 17 15:19:50 PDT 2018
On Dienstag, 17. April 2018 22:35:00 CEST Doug Schaefer via cfe-dev wrote:
> Eclipse CDT does something similar. For each unique collection of compiler
> command line arguments (i.e. for files that build with the same options) we
> add -E -P -v -dD and call the real compiler to get the list of all include
> paths and symbols used for a given parse, including both user and built-in
> ones. Works with both clang and gcc.
> For compiler specifics, we cheat and add macros that work us through the
> parse errors. You likely lose info but at least it rounds up to a pretty
> good parse.
Ah, so you also have something like this  which I forgot to reference in my
If so, can you point me to your version of that file? If you are also using
this approach, and it works for you, then I guess we should share resources
and both work on a common file.
Out of interest: Have you ever tried to parse old clang headers with a CDT
built against a newer clang?
> I'm at the very beginning of trying to figure out how we'd do something
> similar with clangd. This feature will be a must for users with embedded
> systems toolchains which are mainly based on gcc.
> -----Original Message-----
> From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Milian
> Wolff via cfe-dev Sent: Tuesday, April 17, 2018 4:03 PM
> To: Clang Dev <cfe-dev at lists.llvm.org>
> Subject: [cfe-dev] clangd/libclang: how to emulate other compilers?
> Hey all,
> how does clangd or other users of the libclang handle situations where you
> want to parse code that is dependent on a certain other compiler or
> compiler environment? The most common scenario being embedded projects that
> rely on the compiler-builtin defines and include paths to find the sysroot
> include paths and such.
> For KDevelop, which is using libclang, we have tried to build a sort of
> emulation layer that originally yielded good results. The approach is as
> 1) We use the actual compiler that is used to compile a given project, e.g.
> gcc, arm-none-eabi-gcc, ...
> 2) We take this compiler and query it for its builtin defines:
> /usr/bin/gcc -xc++ -std=c++11 -dM -E - < /dev/null
> 3) And also query the include paths:
> /usr/bin/gcc -xc++ -std=c++11 -v -E - < /dev/null
> 4) Then for the libclang calls to clang_parseTranslationUnit2 we pass `-
> nostdinc -nostdinc++` followed by the defines and includes we got from 2)
> and 3).
> Now, for simply things this actually worked quite well. But once you include
> a file that heavily relies on the compiler, such as all the SIMD intrinsic
> headers, you are easily drowning in parse errors. And once you have too
> many parse errors, clang will just give up. We have tried to workaround
> this via compatibility headers such as , but it keeps breaking.
> More recently, we now also got bug reports where the user system has clang3
> and they use that to to compile the code, but then download a KDevelop
> AppImage built against libclang v5 (e.g. via AppImage). Once again this
> easily yields tons of parse errors when encountering system headers that
> are using intrinsics specific to clang v3.
> I am now thinking about removing the emulation layer described above. But
> then it will be essentially impossible to work on a lot of embedded
> projects which rely on the cross compiler defines and include paths...
> So, once again - how do other users of libclang handle this scenario? What
> is the plan for clangd in this regard?
> Milian Wolff
> mail at milianw.de
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the cfe-dev