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: : CommandLine Error: Option 'asm-macro-max-nesting-depth' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options 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): 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: This results in the following dependencies on dynamic libraries as follows: 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) 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 - 2019 MantisBT Team
Powered by Mantis Bugtracker