Then I would suggest you compile the code with the same compiler you build your tool based on...<br><br><div class="gmail_quote">On Fri Nov 21 2014 at 5:14:39 PM Christian Convey <<a href="mailto:christian.convey@gmail.com">christian.convey@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> The question is, why is it important to you whether it's the same AST?<br>
<br>
I'm also generating program traces, which report source locations<br>
based on the DWARF info.  I want to be able to reliably relate the<br>
trace events to the AST.  I want to minimize the risk that the two<br>
don't properly match.<br>
<br>
On Fri, Nov 21, 2014 at 11:00 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br>
> On Fri Nov 21 2014 at 4:40:44 PM Christian Convey<br>
> <<a href="mailto:christian.convey@gmail.com" target="_blank">christian.convey@gmail.com</a>> wrote:<br>
>><br>
>> Hi Manuel,<br>
>><br>
>> What really matters is that when my tool analyzes the target program's<br>
>> source, it assumes the same standard headers that are normally used to<br>
>> build that target program.<br>
>><br>
>> For example, the target program might normally be built with clang<br>
>> 3.4, but my analysis tool is built on clang 3.6.  When my tool<br>
>> analyzes the source code of the target program, I want the analysis to<br>
>> be as though the target program #include'd the 3.4 builtins, not the<br>
>> 3.6 builtins.  Because my goal is to obtain the same AST as the one<br>
>> created during the target program's normal (3.4) build process.<br>
><br>
><br>
> The builtin headers are implementation details of the compiler. If you<br>
> compile a file with a tool based on clang 3.6 and builtin headers of clang<br>
> 3.4 the probability that you *don't* get a correct AST is higher.<br>
><br>
> If you want to get the same AST, you have to use the same version of clang.<br>
> The question is, why is it important to you whether it's the same AST?<br>
><br>
>><br>
>><br>
>> If I understand your suggestion, my analysis would give me an AST<br>
>> based on the clang 3.6 builtins, not based on the 3.4 builtins.  Is<br>
>> that correct?<br>
>><br>
>> Thanks,<br>
>> Christian<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Nov 21, 2014 at 4:35 AM, Manuel Klimek <<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>> wrote:<br>
>> > +1 to needs some refactoring, but generally the trick is: you don't want<br>
>> > to<br>
>> > use the builtin includes that are used by the clang you used to produce<br>
>> > the<br>
>> > compilation database, but the one that is current at the version at<br>
>> > which<br>
>> > you built your *tool*.<br>
>> ><br>
>> > Thus, optimally you'll install your tool into some/bin and the builtin<br>
>> > headers into some/lib/clang/<version>.<br>
>> ><br>
>> > Cheers,<br>
>> > /Manuel<br>
>> ><br>
>> > On Fri Nov 21 2014 at 5:23:16 AM Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> You can set CLANG_RESOURCE_DIR in CMake, or pass -resource-dir (the<br>
>> >> default resource dir is created by `llvm::sys::path::append(<exe-<u></u>path>,<br>
>> >> "..", "lib", "clang", CLANG_VERSION_STRING)`).<br>
>> >><br>
>> >> This logic is actually duplicated in more than one place unfortunately.<br>
>> >> e.g. in CompilerInvocation::<u></u>GetResourcesPath<br>
>> >> (lib/Frontend/<u></u>CompilerInvocation.cpp) and Driver::Driver<br>
>> >> (lib/Driver/Driver.cpp); there's also some nastiness in<br>
>> >> CIndexer::<u></u>getClangResourcesPath. Needs some refactoring.<br>
>> >><br>
>> >> -- Sean Silva<br>
>> >><br>
>> >> On Thu, Nov 20, 2014 at 6:32 PM, Christian Convey<br>
>> >> <<a href="mailto:christian.convey@gmail.com" target="_blank">christian.convey@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> Hi guys,<br>
>> >>><br>
>> >>> I'm developed a standalone tool for analyzing source code.  It uses<br>
>> >>> CommonOptionParser and ClangTool in what I think are the standard<br>
>> >>> ways.<br>
>> >>><br>
>> >>> My tool analyzes some other code ("foo.c") we have.  We build foo.c<br>
>> >>> with clang the system-wide installed version of clang.  Thanks to<br>
>> >>> cmake, we also produce a compilation database for that build of foo.c.<br>
>> >>><br>
>> >>> I'd really like to ensure that when my analysis tool runs, I'd like it<br>
>> >>> to simulate, as closely as possible, the way we normally build foo.c.<br>
>> >>> In particular, I'd like to be sure it's using the same builtin headers<br>
>> >>> and gcc-provided headers.<br>
>> >>><br>
>> >>> Unfortunately, I can't easily copy my analysis tools executable into<br>
>> >>> the same directory as the clang which we use to build foo.c.<br>
>> >>><br>
>> >>> So here's my question: Is there a good way for me to force my tool to<br>
>> >>> search the same include directories, in the same order, as our normal<br>
>> >>> copy of clang does when it's building foo.c?<br>
>> >>><br>
>> >>> I've tried running "clang -### ..." in the build system for foo.c, so<br>
>> >>> that (I think) I get explicit information about the flags being passed<br>
>> >>> to the front-end.  However, I haven't found a way to pass those flags<br>
>> >>> to my analysis tool in a way that CommonOptionsParser and/or ClangTool<br>
>> >>> find acceptable.  For example, they reject "-cc1".<br>
>> >>><br>
>> >>> Thanks,<br>
>> >>> Christian<br>
>> >>> ______________________________<u></u>_________________<br>
>> >>> cfe-dev mailing list<br>
>> >>> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> >>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
>> >><br>
>> >><br>
>> >> ______________________________<u></u>_________________<br>
>> >> cfe-dev mailing list<br>
>> >> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
>> >> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
</blockquote></div>