Frama-C Bug Tracking System

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002368Frama-CPlug-in > clangpublic2018-02-15 23:032018-07-11 15:41
ReporterDeMaze 
Assigned Tovirgile 
PrioritynormalSeveritycrashReproducibilityalways
StatusclosedResolutionfixed 
PlatformGNU/LinuxOSDebianOS Version9.3
Product VersionFrama-C 16-Sulfur 
Target VersionFixed in VersionFrama-C 17-Chlorine 
Summary0002368: Crash on attempt to start framaCIRGen when libs are linked statically and dynamically.
DescriptionOn the attempt to install Frama-Clang regularly as described (see
attached file installation.txt), the executable framaCIRGen exits with
an error when executed. The error message points to a problem with
LLVM. In fact, it depicts one commandline option to be registered more
than once. This occurs on the attempt of using Frama-C to parse C++
source code and when the executable framaCIRGen is invoked manually on
the commandline. I get the following error:

<output nr="0" command="./frama-clang-0.0.4/bin/framaCIRGen">
: CommandLine Error: Option 'asm-macro-max-nesting-depth' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options
</output>

However, this has only been observed ith llvm-5.0 on Debian GNU/Linux
9.3 (my system, see lsb_release_3ffbf_2018-02-10000905) for now. With
llvm 3.9, no such errors happen. Presumably, versions of llvm > 5.0
could also be affected. This seems to be a problem many people have
experienced with llvm related programs [2][3][4][5]. In fact, it has
even been reported for frama-clang [6].

Steps To Reproduce1. Manually install llvm-5.0 as described on https://apt.llvm.org/ [^]
2. Download and build frama-clang as described officially with llvm-5.0
3. Execute ./bin/framaCIRGen
Additional InformationRoot Cause
==========

As far as my investigations revealed, this problem occurs because of
the linking mechanism on Debian GNU/Linux. On this distribution,
libraries of LLVM are built two-fold:

Static archives (lib*.a):
clangFrontend, clangDriver, clangTooling, clanParse, clangSema,
clangAnalysis, clangEdit, clangAST, clangLex, clangSerialization,
clangBasic, LLVMTransformUtils, LLVMBitReader, LLVMMCParser,
LLVMOption

Shared object (lib*.so):
LLVM-5.0

Therefore, it is tried to link them according to their type (lines 74-77, 82-85):
<output nr="1" command="cat frama-clang-0.0.4/Makefile.clang -n | grep 'USEDLIBS' -A 5 -B 5 ">
    69 CFLAGS+=-g
    70 CLANG_LINKFLAGS+=-g
    71 endif
    72
    73 #LINK_COMPONENTS := $(TARGETS_TO_BUILD) asmparser support mc
    74 USEDLIBS = clangFrontend \
    75 clangDriver clangTooling clangParse clangSema \
    76 clangAnalysis clangEdit clangAST clangLex clangSerialization \
    77 clangBasic LLVMTransformUtils LLVMBitReader LLVMMCParser LLVMOption
    78
    79 # for use in main Makefile
    80 default: $(PLUGIN_DIR)/bin/$(TOOLNAME)
    81
    82 $(PLUGIN_DIR)/bin/$(TOOLNAME): $(OBJS) $(PLUGIN_DIR)/bin
    83 $(PRINT_LINKING) $@
    84 $(CXX) $(CLANG_LINKFLAGS) -o $@ \
    85 $(OBJS) $(addprefix -l,$(USEDLIBS)) $(LLVM_LIBS) $(CLANG_SYSLIBS) $(CLANG_LINKFLAGS)
    86
    87 $(PLUGIN_DIR)/bin:
    88 $(MKDIR) $@
    89
    90 clean:
</output>

This results in the following dependencies on dynamic libraries as follows:
<output n="2" command="ldd ./frama-clang-0.0.4/bin/framaCIRGen">
    linux-vdso.so.1 (0x00007ffe31ff5000)
    libLLVM-5.0.so.1 => /usr/lib/x86_64-linux-gnu/libLLVM-5.0.so.1 (0x00007fb4c4825000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb4c44a3000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb4c419f000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb4c3f88000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb4c3be9000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fb4c39e0000)
    libedit.so.2 => /usr/lib/x86_64-linux-gnu/libedit.so.2 (0x00007fb4c37a8000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fb4c35a0000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb4c339c000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007fb4c3172000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb4c2f55000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fb4c2d3b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fb4c9431000)
    libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5 (0x00007fb4c2b18000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fb4c2902000)
</output>

From this output, this assumption can be confirmed because
ligcc_s.so.1 as well as libLLVM-5.0.so.1 occurs. A response on a bug
report of LLVM considers this as rather bad practice
however. Moreover, this is mentioned as a classical problem of LLVM's
"global object-based commandline switch registration" [1]:

"The command line option error is the classical problem one gets due
to the LLVM's global object-based command line switch registration. If
you somehow link the same global object (that registers the command
line option) twice via dynamic loading of the LLVM library twice or
more to the same process, it registers the same command line object
again (when calling the global object initializer), resulting in this
error." [1]

The aforementioned symbol 'asm-macro-max-nesting-depth' occurs both in
libLLVMMCParser.a and libLLVM-5.0.so.1 . Hence, I conjecture these are
the files in conflict.

My Solution
===========

Just link without libLLVMMCParser.a or more precisely, remove
LLVMMCParser from USEDLIBS in Makefile.clang. This seems to work as
C++ code is analyzable again. Please find patches for Makefile.clang
attached which circumvent this problem according to my proposal
(Makefile.clang.patch / Makefile.clang.patch.better). Feel free to
contacting me in case of any further quesions / comments.


References
==========

[1] https://bugs.llvm.org/show_bug.cgi?id=30587#c6 [^]
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768185 [^]
[3] https://bugs.llvm.org/show_bug.cgi?id=31571 [^]
[4] http://llvm.1065342.n5.nabble.com/llvm-dev-LLD-and-LLVM-LINK-LLVM-DYLIB-td104570.html [^]
[5] https://github.com/zig-lang/zig/issues/67 [^]
[6] https://stackoverflow.com/questions/45647503/errors-when-using-the-frama-clang-plugin [^]
TagsNo tags attached.
Attached Files? file icon logs_and_more.tar.xz [^] (6,236 bytes) 2018-02-15 23:03

- Relationships

-  Notes
(0006530)
virgile (developer)
2018-02-16 16:31

Many thanks for this very thorough report. You're right, the issue stems from dynamic linking of LLVM libraries, which is the default when using compilation flags given by llvm-config as shipped by Debian, contrarily to what upstream does. This affects all LLVM versions >= 3.9, not just 5.0

The issue was in fact reported a few weeks ago in the context of a collaborative project, and is fixed internally. A new release re-enabling compatibility with LLVM Debian package should be published soon
(0006531)
virgile (developer)
2018-02-19 17:49

Frama-Clang release 0.0.5 is compatible with Clang and LLVM Debian packages
(0006578)
signoles (manager)
2018-07-11 15:34
edited on: 2018-07-11 15:41

Fixed in Frama-C Chlorine.


- Issue History
Date Modified Username Field Change
2018-02-15 23:03 DeMaze New Issue
2018-02-15 23:03 DeMaze Status new => assigned
2018-02-15 23:03 DeMaze Assigned To => virgile
2018-02-15 23:03 DeMaze File Added: logs_and_more.tar.xz
2018-02-16 16:31 virgile Note Added: 0006530
2018-02-19 17:49 virgile Note Added: 0006531
2018-02-19 17:49 virgile Status assigned => resolved
2018-02-19 17:49 virgile Resolution open => fixed
2018-07-11 15:33 signoles Fixed in Version => Frama-C 16-Sulfur
2018-07-11 15:34 signoles Status resolved => closed
2018-07-11 15:34 signoles Note Added: 0006578
2018-07-11 15:40 signoles Fixed in Version Frama-C 16-Sulfur => Frama-C 17-Chlorine
2018-07-11 15:41 signoles Note Edited: 0006578 View Revisions


Copyright © 2000 - 2018 MantisBT Team
Powered by Mantis Bugtracker