Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep only a single clone of LLVM #14

Closed
mabrowning opened this issue Dec 13, 2017 · 8 comments
Closed

Keep only a single clone of LLVM #14

mabrowning opened this issue Dec 13, 2017 · 8 comments

Comments

@mabrowning
Copy link

deps/llvm AND deps/fileformat/deps/llvm AND deps/capstone2llvmir/deps/llvm AND deps/fnc-patterns/deps/fileformat/deps/llvm ??

Look into conan for sane c++ dependency management...

@PeterMatula
Copy link
Collaborator

Yeah, we are aware. The whole git submodule thing, or packages in C++ in general, is kind of an ongoing issue. We will explore the possibilities to make this better in future, but it is not of the highest priority. Only one LLVM should be built and disk space is cheap :-D

@mewmew
Copy link

mewmew commented Dec 13, 2017

Would it be possible to utilize local installations of LLVM on the system? For instance, Arch Linux provides both the latest LLVM release (5.0 package) as a binary package download, and the 3.9 release (3.9 package).

For the compile time it would be really wonderful to make use of the LLVM libraries installed on the system. On my laptop, it took 1.5 hours to build retdec (#5 (comment)). Most of that was probably due to building LLVM.

@s3rvac
Copy link
Member

s3rvac commented Dec 13, 2017

@mewmew Unfortunately not, because (1) we currently need exactly version 3.9.1 and, most importantly, (2) our version of LLVM contains many customizations that we need for RetDec.

Anyhow, even though a cloned repository contains multiple copies of LLVM, only one of them is built. The dependencies should be set correctly. If you believe they are incorrect, please open an issue.

@PeterMatula
Copy link
Collaborator

Yes, LLVM plays a major role in compilation time.

No, it is not possible to use local LLVM for the following reasons:

  • There are often big differences between LLVM versions. For example, there is no way one program could be used with both 3.9 and 5.0 versions. Fixing RetDec to a certain version is necessary and avoids confusion and problems that would be caused by users trying to use their own versions.
  • Even more important, we do not use vanilla LLVM. See https://github.com/avast-tl/llvm for details. LLVM is great, but it is also aimed at compilation. Sometimes it works against us and we need to hack it a bit. We try to keep hacks to minimum, but I dont know if we would be able to get rid of them altogether. In fact, we might need more of them, since I’m fairly certain there are still some glitches in the matrix - related to code lowering, optimizations, and LLVM’s habit of discarding code with undefined behavior - understandable for compilers, not so good in reverse engineering.

@sandsmark
Copy link

just to get a bit clearer overview of what the actual differences are: sandsmark/llvm@3c47bd2

doesn't look impossible to eventually use a vanilla llvm, but it seems like it would require some work to expose the necessary knobs to adjust behavior.

@PeterMatula
Copy link
Collaborator

Options mentioned in duplicate #48:

Take a look a this project which is using repo: https://github.com/aurora-fw
Repo Tool: https://source.android.com/setup/using-repo

@MerovingianByte
Copy link

Maybe if you could contact the llvm guys to give options to disable code discarding and optimizations, let it be more configurable, then you guys wouldn't need to hack it and use the vanilla version instead.

@PeterMatula
Copy link
Collaborator

We got rid of all git submodules. See https://github.com/avast-tl/retdec/wiki/Project-Repository-Structure for more details. See #92 how to fix your repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants