Add initial support for position-independent executables.

[lifthrasiir]

What an appropriate PR for pi(e) day, heh. :) Anyway, this PR adds two features that enable the support for position-independent executables:

• Disables the address randomization after fork. While this does not directly enable PIE support (AFAIK, x86_64 Linux always relocates the PIE at 0x555555554000) this should help any potential issues from ASLR.
• Reads the "base address" (or more accurately, relocation) of PIE from solib_wrapper. This has some design implications, and I went to the easiest way possible: DWARF parsing is deferred until solib_wrapper returns. I think we already have to wait for that, so this should not be a big problem.

Again with the prior PR, I haven't written a proper test case for this. (I tried to run test cases, but I'm blocked on pybot downloads...) Any executable compiled with gcc -pie -fpie -fPIE should work.

[coveralls]

Coverage decreased (-0.5%) to 63.4% when pulling aab8928 on lifthrasiir:pie into bee0aaf on SimonKagstrom:master.

[SimonKagstrom]

Haha! Did you wait with the submission until pi-day or was it just lucky coincidence?

Anyway, very nice work and thanks for the submission! I can add test cases to cover this, it's not difficult to do. As for pybot, I install it with the "pip" tool, which seems to work in the Travis builds at least (see '''travis/Makefile''' for how it's setup in Ubuntu).

[lifthrasiir]

@SimonKagstrom Just a lucky coincidence. ;) As the above issue linked suggests, I was trying to revive kcov for Rust programs (which are now compiled as a PIE by default, and non-PIE codegen needs some non-trivial work). Turned out that this too was a non-trivial task though.

I've finally figured out what was wrong with my local pip (easy_install -U pip was helpful). I've added basic tests for PIE support as #78. How do you test locally by the way? I haven't found any shortcut and had to resort with make -B -f travis/Makefile build && cd build-tests && WORKSPACE=pwd/.. pybot --noncritical not_ready ../tests/robot-framework/kcov-tests.txt (oops).

[SimonKagstrom]

Locally I do more or less what you did. My build directories for the tests and kcov itself are laid out the same way as for travis (or really, the other way around), so I just do

WORKSPACE=`pwd`/.. pybot --noncritical not_ready ../tests/robot-framework/kcov-tests.txt

in the build-tests directory.

Anyway, I added a couple of more tests for PIE executables.

One thing which doesn't work for these is coverage accumulation, i.e., data from multiple runs. I added the pie-accumulate test (failing) which checks for this. It's not an error in your commit, but rather a limitation in the kcov implementation which stores raw addresses and "re-runs" these when the binary is started again. Shared libraries used to have the same bug (Issue #54), which was solved through storing an offset instead of the absolute address.

PIE executables should be possible to handle in the same way. Another possibility would be to use the same method as in Python/Bash (where a file/line hash is stored instead), but without being careful, it would mean missing information about partial hits.

Good to hear that kcov gets used by the way :-)