BOLT PIC/PIE/Shared objects support.

What is the status of PIC/PIE support? Is it going to be supported at some point or there are no plans?

My use case is that some of my performance critical code are implemented as native C code in otherwise java application via JNI.

Do you foresee for it to be feasible to optimise layout of shared objects?

Jul 14 '18 04:07 J-cztery

We will support PIEs and .so's in the future. Most of the functionality is already there. Can't provide any firm timelines, though.

Jul 14 '18 17:07 maksfb

The readme now claims PIE/.so support is in. I've not tried it yet, so I have no idea how well it works.

Jan 19 '19 00:01 nolanl

Correct. It's not well-tested, but it is there. For now, I recommend to recompile the code with -fno-jump-tables compiler option, or at the very least make sure -use-old-text BOLT option is disabled.

Jan 19 '19 03:01 maksfb

Tried it, seems to work on a mix of rust/C/C++/asm linked into a .so to run in an Intel SGX enclave.

Even without -fno-jump-tables. It did print this: BOLT-INFO: forcing -jump-tables=move as PIC jump table was detected in function _ZN42_$LT$$RF$T$u20$as$u20$core..fmt..Debug$GT$3fmt17h09b4766b8554dd86E/1 but seems to work fine.

Feb 05 '19 17:02 nolanl

Great! Sometimes PIC jump tables can originate from pre-compiled libraries or from assembly code. This warning is normal.

Feb 05 '19 18:02 maksfb

How is running BOLT on a shared object supposed to work exactly? I'm playing with optimizing a .so that is statically linked into my program. I tried creating a profile against the program and running llvm-bolt against the library, essentially:

$ perf record -e cycles:u -j any,u -o my_prog.data -- ./my_prog
$ perf2bolt -p my_prog.data -o my_prog.fdata my_prog
$ llvm-bolt my_lib.so  -o my_lib.bolt.so -data=my_prog.fdata  -v=2 -use-old-text=false

But that gave me the following error:

llvm-bolt BOLT/libHSrts_thr-ghc8.6.3.DWARF.relocs_build3.so  -o rts_hello_plain_8.6.3.bolt -data=perf8.6.3.fdata  -v=2 -use-old-text=false               
BOLT-INFO: Target architecture: x86_64
BOLT-INFO: shared object or position-independent executable detected
BOLT-INFO: first alloc address is 0x0
BOLT-INFO: creating new program header table at address 0x200000, offset 0x200000
BOLT-INFO: enabling relocation mode
BOLT-INFO: setting size of function _init to 23 (was 0)
BOLT-INFO: setting size of function deregister_tm_clones/crtstuff.c/1(*2) to 64 (was 0)
BOLT-INFO: setting size of function register_tm_clones/crtstuff.c/1(*2) to 80 (was 0)
BOLT-INFO: setting size of function __do_global_dtors_aux/crtstuff.c/1(*2) to 64 (was 0)
BOLT-INFO: setting size of function frame_dummy/crtstuff.c/1(*2) to 48 (was 0)
BOLT-INFO: setting size of function _fini to 9 (was 0)
LLVMSymbolizer: error reading file: No such file or directory
#0 0x00005563a001baea (llvm-bolt+0xbabaea)
#1 0x00005563a0019cde (llvm-bolt+0xba9cde)
#2 0x00005563a0019e02 (llvm-bolt+0xba9e02)
#3 0x00007fa1987330c0 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x110c0)
#4 0x000055639f6aee7a (llvm-bolt+0x23ee7a)
#5 0x000055639f6cc8aa (llvm-bolt+0x25c8aa)
#6 0x000055639f6df720 (llvm-bolt+0x26f720)
#7 0x000055639f5b2e4b (llvm-bolt+0x142e4b)
#8 0x00007fa1972b62e1 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e1)
#9 0x000055639f5ff93a (llvm-bolt+0x18f93a)
Stack dump:
0.	Program arguments: llvm-bolt BOLT/libHSrts_thr-ghc8.6.3.DWARF.relocs_build3.so -o rts_hello_plain_8.6.3.bolt -data=perf8.6.3.fdata -v=2 -use-old-text=false 
[1]    31113 segmentation fault  llvm-bolt BOLT/libHSrts_thr-ghc8.6.3.DWARF.relocs_build3.so -o   -v=2

I haven't tried recompiling with -fno-jump-tables. Does it sound like that might help my situation? Is what I'm trying to do sensible?

Feb 23 '19 19:02 jberryman