[cfe-dev] How does scan-build
Дилян Палаузов via cfe-dev
cfe-dev at lists.llvm.org
Thu Jul 18 04:47:09 PDT 2019
Hello Christian,
this thread is about clarifying how does scan-build exactly work and how shall one use the clang static analyzer out of
a build system to inspect a single file.
Concernig LTO, for linking static libraries and other operations, the build systems expects to have working an, nm and
ranlib. The latter work with LTO, only if the lto plugin is installed in $(libdir)/bfd-plugins. The alternative is to
choose the right tool out of llvm-ar, llvm-ar-8, llvm-ar-8.0, gcc-ar, gcc-ar-7 and gcc-ar-7.0 depending on the system
(so not to use llvm-ar-6, if the used clang is verison 7, llvm-ar-6, llvm-ar-7 and llvm-ar-8 are all available on the
system).
-fuse= is for the compiler, but cannot be passed to an/nm/ranlib. I can go into details, like some things can be linked
with ld.bfd but not with ld.gold, others can be linked with ld.gold but not with ld.bfd and gcc9 accepts -fuse-ld=bfd,
but gcc8 does not; some versions of ld.bfd generate debug information, that some versions of valgring cannot read and so
on.
This thread is not about LTO, but about passing a big source file to the static analyzer. My question, whether the
static analyzer analyzes the object file or the source file, e.g. was not answered, so I do not know, whether passing
-O3 to “scan-build cc -O3…” speeds the process or makes things worse.
Regards
Дилян
On Thu, 2019-07-18 at 23:30 +1200, Christian Gagneraud wrote:
> On Thu, 18 Jul 2019 at 23:14, Дилян Палаузов <dpa-llvm at aegee.org> wrote:
> > Hello Chirstian,
> >
> > for the rationale to join several input files into one, and pass that one to the static analyzer, see the thread Subj:
> > “Many .c files as input to scan-build” Thread-Id: <e0b6149d092be2f191052aed11be0d2bf7b83d2a.camel at aegee.org> . The idea
> > is to get more useful results out of the static analyzer by providing it with more complete picture of everything: a
> > single source file containg all information.
> >
> > As far as LTO is concerned, it is not ready for the prime time. In order of ar, nm and ranlib to work with LTO, the
> > installation process of clang must install LLVMgold.so under ${libdir}/bfd-plugins otherwise the build system has to do
> > a lot of magic and most build systems don’t do that magic (part of the magic is to call on some systems gcc-ar-5 and on
> > others gcc-ar-5.0 or alike. In fact cmake is the only build system to implement this magic completely, as of January
> > 2019). Build systems want to use just ar or nm. I posted this to llvm-dev,
> > http://lists.llvm.org/pipermail/llvm-dev/2018-March/122018.html and there is no interest to fix this. Neither is there
> > interest on gcc’s side.
>
> Sorry, i haven't read any of the links above. Have you tried to simply
> get rid of GNU binutils/gcc?
> eg, use llvm all the way? -fuse-ld=lld and the likes? My experience
> with gcc LTO (+dwarf) is so far pretty bad:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871
> Just to name a few,I'm sure there are more.
More information about the cfe-dev
mailing list