[prev in list] [next in list] [prev in thread] [next in thread]
List: cfe-dev
Subject: Re: [cfe-dev] standalone tool: best way to find built-in includes?
From: Sean Silva <chisophugis () gmail ! com>
Date: 2014-11-25 0:15:27
Message-ID: CAHnXoanDBwJ5qv1v3KsyP6yaMUx74fr8T+c-Ga0AYpSSDOHoqQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Nov 21, 2014 at 5:59 PM, Christian Convey <
christian.convey@gmail.com> wrote:
> Hi Sean:
> > It's actually possible for it to fail to build with the wrong builtin
> headers. E.g. an intrinsic was changed from using an __builtin_* function
> to using a different one that is not present in the other compiler.
>
> Are you basically reinforcing Manuel's warning, by saying there's a
> real-world example of this happening?
>
Yes.
-- Sean Silva
>
> Thanks,
> Christian
>
> On Fri, Nov 21, 2014 at 7:50 PM, Sean Silva <chisophugis@gmail.com> wrote:
> >
> >
> > On Fri, Nov 21, 2014 at 8:00 AM, Manuel Klimek <klimek@google.com>
> wrote:
> >>
> >> On Fri Nov 21 2014 at 4:40:44 PM Christian Convey
> >> <christian.convey@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.
> >
> >
> > It's actually possible for it to fail to build with the wrong builtin
> > headers. E.g. an intrinsic was changed from using an __builtin_*
> function to
> > using a different one that is not present in the other compiler.
> >
> > -- Sean Silva
> >
> >>
> >>
> >> 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@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@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@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@cs.uiuc.edu
> >>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> cfe-dev mailing list
> >>> >> cfe-dev@cs.uiuc.edu
> >>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
>
[Attachment #5 (text/html)]
<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov \
21, 2014 at 5:59 PM, Christian Convey <span dir="ltr"><<a \
href="mailto:christian.convey@gmail.com" \
target="_blank">christian.convey@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Hi Sean:<br> <span class="">> It's actually possible \
for it to fail to build with the wrong builtin headers. E.g. an intrinsic was changed \
from using an __builtin_* function to using a different one that is not present in \
the other compiler.<br> <br>
</span>Are you basically reinforcing Manuel's warning, by saying there's \
a<br> real-world example of this \
happening?<br></blockquote><div><br></div><div>Yes.</div><div><br></div><div>-- Sean \
Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
Thanks,<br>
Christian<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 21, 2014 at 7:50 PM, Sean Silva <<a \
href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br> ><br>
><br>
> On Fri, Nov 21, 2014 at 8:00 AM, Manuel Klimek <<a \
href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br> >><br>
>> On Fri Nov 21 2014 at 4:40:44 PM Christian Convey<br>
>> <<a href="mailto:christian.convey@gmail.com">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>
><br>
> It's actually possible for it to fail to build with the wrong builtin<br>
> headers. E.g. an intrinsic was changed from using an __builtin_* function to<br>
> using a different one that is not present in the other compiler.<br>
><br>
> -- Sean Silva<br>
><br>
>><br>
>><br>
>> If you want to get the same AST, you have to use the same version of<br>
>> clang. The question is, why is it important to you whether it's the \
same<br> >> 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">klimek@google.com</a>> wrote:<br> >>> \
> +1 to needs some refactoring, but generally the trick is: you don't<br> \
>>> > want 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">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<br>
>>> >> `llvm::sys::path::append(<exe-path>,<br>
>>> >> "..", "lib", "clang", \
CLANG_VERSION_STRING)`).<br> >>> >><br>
>>> >> This logic is actually duplicated in more than one place<br>
>>> >> unfortunately.<br>
>>> >> e.g. in CompilerInvocation::GetResourcesPath<br>
>>> >> (lib/Frontend/CompilerInvocation.cpp) and Driver::Driver<br>
>>> >> (lib/Driver/Driver.cpp); there's also some nastiness in<br>
>>> >> CIndexer::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">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<br> >>> >>> \
foo.c.<br> >>> >>><br>
>>> >>> I'd really like to ensure that when my analysis tool \
runs, I'd like<br> >>> >>> 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<br> >>> >>> 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<br> >>> >>> 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<br> >>> >>> ClangTool<br>
>>> >>> find acceptable. For example, they reject \
"-cc1".<br> >>> >>><br>
>>> >>> Thanks,<br>
>>> >>> Christian<br>
>>> >>> _______________________________________________<br>
>>> >>> cfe-dev mailing list<br>
>>> >>> <a \
href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br> \
>>> >><br> >>> >><br>
>>> >> _______________________________________________<br>
>>> >> cfe-dev mailing list<br>
>>> >> <a \
href="mailto:cfe-dev@cs.uiuc.edu">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/mailman/listinfo/cfe-dev</a><br> ><br>
><br>
</div></div></blockquote></div><br></div></div>
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
[prev in list] [next in list] [prev in thread] [next in thread]