VR: use fixed and refactored version

[GiraffeReversed]

Known issues:

• due to splitting the analysis source files to .h and .cpp, I changed the way the resulting libraries are linked to the ValueRelationsPlugin and also to the new vr_tests; the way is probably not the desired one, since it requires the variable CMAKE_INSTALL_LIBDIR to be set with the path to the dg install directory (which probably misuses the CMake in several ways that I know little about)

Related PR to dg:
mchalupa/dg#403

[lzaoral]

Remarks:

• Some files do not end with a newline.
• Format the changes files using the clang-format config file from dg.

[lzaoral]

• ../src/jsoncpp.cpp -- What if jsoncpp installed by a package manager is used?
• ${CMAKE_SOURCE_DIR}/analyses/value_relations_plugin.cpp - Link with the corresponding plug-in so that the code that's actually going to be used by the instrumenter is tested.

[GiraffeReversed]

I was not able to test the fix as the libjsoncpp-dev on Ubuntu 20.04 contains version 1.7.4, but at least 1.9.2 is required (or at least I hope I interpret the problem correctly).

As for linking ValueRelationsPlugin directly, when I tried the naive solution of dropping the value_relations_plugin.cpp and linking ValueRelationsPlugin as library instead, I got the following error:

CMake Error at tests/CMakeLists.txt:39 (target_link_libraries):
Target "ValueRelationsPlugin" of type MODULE_LIBRARY may not be linked into
another target. One may link only to INTERFACE, OBJECT, STATIC or SHARED
libraries, or to executables with the ENABLE_EXPORTS property set.

I do not feel like it's my call to change the ValueRelationsPlugin library's type and no attempt to set ENABLE_EXPORTS helped.

[lzaoral]

Yeah, sorry. I forgot that the plug-ins are not meant to be directly linked to other targets. You can re-use the libdl-like machinery of Analyzer::analyse (OT: This is a really deceitful name for a method that just loads and initializes a dynamic library on-demand...):

sbt-instrumentation/src/instr_analyzer.cpp

Lines 13 to 41 in ad75851

	unique_ptr<InstrPlugin> Analyzer::analyze(const string &path,
	llvm::Module* module)
	{
	if (path.empty())
	return nullptr;
	string err;
	auto DL = llvm::sys::DynamicLibrary::getPermanentLibrary(path.c_str(),
	&err);
	if (!DL.isValid()) {
	cerr << "Cannot open library: " << path << "\n";
	cerr << err << endl;
	return nullptr;
	}
	InstrPlugin* (*create)(llvm::Module*);
	void *symbol = DL.getAddressOfSymbol("create_object");
	if (!symbol) {
	cerr << "Cannot load symbol 'create_object' from " << path << endl;
	return nullptr;
	}
	create = reinterpret_cast<InstrPlugin *(*)(llvm::Module*)>(symbol);
	unique_ptr<InstrPlugin> plugin(create(module));
	return plugin;
	}

[lzaoral]

Clang version should be configured by the build system to use version compatible with LLVM that this project was compiled with.

[GiraffeReversed]

Well, I solved this, but the solution feels pretty hacked.

[mchalupa]

I haven't went through the commits, but I have tested them repeatedly (and they ran in SV-COMP'22), so once all cosmetic issues are solved, I think they are good to be merged.

[trtikm]

This is quite big PR. I will need some assistance to fully understand the changes.

Dismissing because I'm no longer associated with this project in any way for few last months..