danog/gllvm
1
0
Fork 0
mirror of https://github.com/danog/gllvm.git synced 2024-11-26 19:24:40 +01:00
Code Issues Packages Projects Releases Wiki Activity

Added some details about whats under the hood of both wllvm, and gllvm.

Browse Source
This commit is contained in:
Ian A. Mason 2019-06-10 13:47:18 -07:00
parent fcb3406452
commit d7da603429
1 changed files with 35 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
README.md
View File

@ -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)