[cfe-dev] standalone tool: best way to find built-in includes?

[Manuel Klimek]

On Fri Nov 21 2014 at 4:40:44 PM Christian Convey <
christian.convey at gmail.com> wrote:

> Hi Manuel,
>
> What really matters is that when my tool analyzes the target program's
> source, it assumes the same standard headers that are normally used to
> build that target program.
>
> For example, the target program might normally be built with clang
> 3.4, but my analysis tool is built on clang 3.6.  When my tool
> analyzes the source code of the target program, I want the analysis to
> be as though the target program #include'd the 3.4 builtins, not the
> 3.6 builtins.  Because my goal is to obtain the same AST as the one
> created during the target program's normal (3.4) build process.
>

The builtin headers are implementation details of the compiler. If you
compile a file with a tool based on clang 3.6 and builtin headers of clang
3.4 the probability that you *don't* get a correct AST is higher.

If you want to get the same AST, you have to use the same version of clang.
The question is, why is it important to you whether it's the same AST?


>
> If I understand your suggestion, my analysis would give me an AST
> based on the clang 3.6 builtins, not based on the 3.4 builtins.  Is
> that correct?
>
> Thanks,
> Christian
>
>
>
>
>
> On Fri, Nov 21, 2014 at 4:35 AM, Manuel Klimek <klimek at google.com> wrote:
> > +1 to needs some refactoring, but generally the trick is: you don't want
> to
> > use the builtin includes that are used by the clang you used to produce
> the
> > compilation database, but the one that is current at the version at which
> > you built your *tool*.
> >
> > Thus, optimally you'll install your tool into some/bin and the builtin
> > headers into some/lib/clang/<version>.
> >
> > Cheers,
> > /Manuel
> >
> > On Fri Nov 21 2014 at 5:23:16 AM Sean Silva <chisophugis at gmail.com>
> wrote:
> >>
> >> You can set CLANG_RESOURCE_DIR in CMake, or pass -resource-dir (the
> >> default resource dir is created by `llvm::sys::path::append(<exe-path>,
> >> "..", "lib", "clang", CLANG_VERSION_STRING)`).
> >>
> >> This logic is actually duplicated in more than one place unfortunately.
> >> e.g. in CompilerInvocation::GetResourcesPath
> >> (lib/Frontend/CompilerInvocation.cpp) and Driver::Driver
> >> (lib/Driver/Driver.cpp); there's also some nastiness in
> >> CIndexer::getClangResourcesPath. Needs some refactoring.
> >>
> >> -- Sean Silva
> >>
> >> On Thu, Nov 20, 2014 at 6:32 PM, Christian Convey
> >> <christian.convey at gmail.com> wrote:
> >>>
> >>> Hi guys,
> >>>
> >>> I'm developed a standalone tool for analyzing source code.  It uses
> >>> CommonOptionParser and ClangTool in what I think are the standard
> >>> ways.
> >>>
> >>> My tool analyzes some other code ("foo.c") we have.  We build foo.c
> >>> with clang the system-wide installed version of clang.  Thanks to
> >>> cmake, we also produce a compilation database for that build of foo.c.
> >>>
> >>> I'd really like to ensure that when my analysis tool runs, I'd like it
> >>> to simulate, as closely as possible, the way we normally build foo.c.
> >>> In particular, I'd like to be sure it's using the same builtin headers
> >>> and gcc-provided headers.
> >>>
> >>> Unfortunately, I can't easily copy my analysis tools executable into
> >>> the same directory as the clang which we use to build foo.c.
> >>>
> >>> So here's my question: Is there a good way for me to force my tool to
> >>> search the same include directories, in the same order, as our normal
> >>> copy of clang does when it's building foo.c?
> >>>
> >>> I've tried running "clang -### ..." in the build system for foo.c, so
> >>> that (I think) I get explicit information about the flags being passed
> >>> to the front-end.  However, I haven't found a way to pass those flags
> >>> to my analysis tool in a way that CommonOptionsParser and/or ClangTool
> >>> find acceptable.  For example, they reject "-cc1".
> >>>
> >>> Thanks,
> >>> Christian
> >>> _______________________________________________
> >>> cfe-dev mailing list
> >>> cfe-dev at cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141121/9f26a99a/attachment.html>