Pin 3.7 build issues

[Jinmo]

Currently QSYM is using Pin 2.14 build 71313, and it doesn't support latest linux kernel versions. I wonder why, and tried to build it with Pin 3.7, but there were some issues:

• Latest PinCRT uses memory.h but it's overriden by ./memory.h on pintool/. Renaming it into _memory.h fixed the issue.
• seems like LLVM's APInt, APSInt uses C++11 standard, but Pin's latest approach is replacing all C++ headers into their own one (it's not C++ >= 11 compatible), maybe using another integer class or copying whole dependencies into pintool/third_party/llvm will work.

[insuyun]

Does libz3.so work in PIN 3.7?

[Jinmo]

doesn't work with the DT_HASH issue.

Currently trying to build it with sysv, and static shared library..

[Jinmo]

This is gonna be harder, since pin's dlopen doesn't support hash-style=gnu, just supports hash-style=sysv.

Trial 1. recompiling all libs

I tried to recompile all the glibc ~ z3 chain with LDFLAGS='-Wl,--hash-style=sysv' to support this because Pin complains about DT_HASH's nonexistence if any of dependency doesn't have it. (--static-libc fails on clang, --static-libgcc/--static-lib[std]c++ works on clang but fails on gcc, ...)

Maybe ubuntu libc/stdc++/c++ packages are not built for this kind of usage. (building a static library) Even LLVM C++ library has dependency to glibc.

Currently I've failed to build custom glibc locally because of binutils internal bug.. I'll retry it. But maybe waiting for PinCRT updates or using other libc like musl seems to be a better choice.

(or using pin 7xxxx build, because I think using non-PinCRT libraries can cause some not-intel-supported unexpected bugs from libc)

Trial 2. Building Z3 with PinCRT

I tried and it doesn't work. PinCRT doesn't support C++11 (giving "std::move is not a member of std" error).

[insuyun]

Yes. I had same issues when I tried to use PIN 3.7.
I hope we could find better DBT for QSYM.

[Jinmo]

Update: built glibc, but encountered error:

dlopen failed: unknown reloc type 18 @ 0x7ffff4400ea0 (1190)

... Maybe glibc is not appropriate way to build this. Separating solver with tool process would work.

Update 2: since the linker is from bionic, I'm trying bionic ld.

[Jinmo]

Maybe it can be merged to #4? I'll give up this approach since it would cause many uncontrollable bugs because of hacking PinCRT.