Michael Bentley, PhD

Implementation is finished, but needs the following before we can close it: - Documentation - Unit tests (as much as is reasonable)

The `--allow-multiple-definitions` flag along with two versions of the same object file works, but only because of implementation details of GNU ld. With the multiple definitions, the first seen is...

So far in the paper, I've been using the "baseline compilation" term. What do you think about that term? A secondary choice would maybe be the "control compilation".

The FLiT ecosystem has been simplified. There is a docker container I have been using privately. After making it public, or adding the Dockerfile to the repository, I should be...

Actually, looking at the documentation for GNU `ld`, it says the following: ``` --allow-multiple-definition -z muldefs Normally when a symbol is defined multiple times, the linker will report a fatal...

The GNU gold linker (`ld.gold`) doesn't specify this detail nor does the LLVM linker (`lld`). They support the `--allow-multiple-definitions`, but they just say that it allows linking with multiple definitions....

Another option: put the object files under test into shared libraries and use [elf_hook](https://github.com/shoumikhin/ELF-Hook). We could probably embed the source code into FLiT if we choose to go this route....

Note: the failure was not at link-time, but rather a linker error at runtime. They were missing symbols, such as `undefined reference to _intel_fast_memcpy`.

Specifically, I want to simplify the doctests for `flit_bisect.py` function `run_make()`.

Also, simplify doctests for `extract_make_var()` and `extract_make_vars()` in `flitutil.py`.