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

Update README.md

Browse Source 
Corrections to the under the hood yada yada.
This commit is contained in:
Ian A Mason 2019-06-10 13:54:51 -07:00 committed by GitHub
parent d7da603429
commit f9891c0fe7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
README.md
View File

@ -121,18 +121,18 @@ 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
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.
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.
`objdump` on *nix, and `otool` on OS X.
Both tools then use `llvm-link` or `llvm-ar` to combine the bitcode files
into the desired form.