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)