From d7da60342987ec83a090f17af4ea991f91f69208 Mon Sep 17 00:00:00 2001 From: "Ian A. Mason" Date: Mon, 10 Jun 2019 13:47:18 -0700 Subject: [PATCH] Added some details about whats under the hood of both wllvm, and gllvm. --- README.md | 38 +++++++++++++++++++++++++++++++++++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 1f15da4..c65357d 100644 --- a/README.md +++ b/README.md @@ -87,7 +87,7 @@ get-bc pkg-config which will produce the bitcode module `pkg-config.bc`. -If clang and the llvm tools are not in your `PATH`, you will need to set some +If clang and the llvm tools are not in your `PATH`, you will need to set some environment variables. @@ -100,12 +100,44 @@ environment variables. environment variables `LLVM_LINK_NAME` and `LLVM_AR_NAME` in an analogous way. -Another useful environment variable is `WLLVM_CONFIGURE_ONLY`. Its use is explained in the -README of [wllvm](https://github.com/SRI-CSL/whole-program-llvm). +Another useful environment variable is `WLLVM_CONFIGURE_ONLY`. Its use is explained in the +README of [wllvm](https://github.com/SRI-CSL/whole-program-llvm). `gllvm` does not support the dragonegg plugin. All other features of `wllvm`, such as logging, and the bitcode store, are supported in exactly the same fashion. + +## Under the hoods + + +Both `wllvm` and `gllvm` toolsets do much the same thing, but the way they do it is +slightly different. The `gllvm` toolset's code base is written in +`golang`, and is largely derived from the `wllvm`'s python codebase. + +Both generate object files and bitcode files using the compiler. `wllvm` +can use `gcc` and `dragonegg`, `gllvm` can only use `clang`. The `gllvm` toolset +does these two tasks in parallel, while `wllvm` does them sequentially. +This together with the slowness of python's `fork exec`-ing, and it's +interpreted nature accounts for the large efficiency gap between the +tool toolsets. + +Both inject the path of the bitcode version of the .o file into a +dedicated segment of the .o file itself. This segment is the same across +toolsets, so extracting the bitcode can be done by the appropriate +tool in either toolset. On *nix both toolsets use objcopy to add the +segment, while on OS X they use ld. + +When the object files are linked into the resulting library or +executable, the bitcode path segments are appended, so the resulting +binary contains the paths of all the bitcode files that constitute the +binary. To extract the sections the `gllvm` toolset uses the golang +packages `"debug/elf"` and `"debug/macho"`, while the `wllvm` toolset uses +`objdump` on *nix, and `otool` on OScX. + +Both tools then use `llvm-link` or `llvm-ar` to combine the bitcode files +into the desired form. + + ## License `gllvm` is released under a BSD license. See the file `LICENSE` for [details.](LICENSE)