Open ckxckx opened 5 years ago
I just want to add to this issue. We receive a similar error when using multiverse with the SPEC CPU 2006 benchmarks. We do not see the error with the simplest example that comes with multiverse.
Specifically, we get the bug when we run multiverse with bzip2 from SPEC CPU 2006.
If we do:
python icount.py ./bzip2
It does produce a bzip2-r executable file, but the last line of output states:
WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location
If we run the bzip2-r executable under gdb and watch the global counter that was inserted by icount.py, we can see it reach instructions that increment the counter exactly 11 times. Then, the program reaches an uninstrumented version of the main routine, and executes the remainder of the program without instrumentation.
Any help would be greatly appreciated. Thanks.
Could you run the file
command on your version of bzip2 and share the output? It will help to know whether it is 32-bit or 64-bit and whether it is a position-independent executable.
This is a 64-bit binary. We have tried compiling with a 32-bit binary, but we had some other issues with the 32-bit binary. Here's the output of file:
$ file bzip2 $ bzip2: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=880bca2d84e71df63b534d06486dff74e22d3baa, not stripped
FYI, this morning I tried with a statically linked binary (i.e., compiled with -static), and received some additional warnings along with the same warning from earlier. Here's the output of file on the static binary:
$ file bzip2 $ bzip2: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=7b706cefab8733d23fff6e93b89bd9790530af7f, not stripped
And from icount.py:
$ python icount.py bzip2 ... WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location
My 64-bit binary for spec's bzip2 works fine for me. It shows that about 983 thousand instructions executed when running bzip2 with no arguments and about 377 billion instructions executed when I ran bzip2 with icount.py as the file to compress.
My compiled version of bzip2 appears to use an older Linux ABI version:
ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=acba1409b496f99cdde7fe99811ed4e49ce0a91c, not stripped
Besides that, I can't be sure what might be causing the problem without more information. Perhaps try compiling a version of bzip2 that isn't from the spec benchmark. If that version doesn't work, upload the original and rewritten binaries from that version somewhere and I can try to take a look.
Could you send me the exact Linux distribution and kernel version you are using? Thanks!
Could you also share which version of Pwntools you are using?
The Linux distribution is Ubuntu 14.04.1, kernel version 4.4.0, pwntools version 2.2. All fairly old versions since this was developed a few years ago.
I've got multiverse working properly now inside a VM with those specific versions of everything. Appreciate the help!
When the warning "WARNING elfmanip._update_phdr_entry :: problem finding LOAD segment containing new phdr location" happens in the rewriting procedure, the rewrited binary will not work well.