Using Bolt in dynamic libary, occur Segmentation fault

[ccx1225]

#1、 demo

the above is the small case, the hello.c is so, the version of gcc is 7.3
gcc hello.c -o libhello.so -I../include -fPIC -shared

gcc main.c -o main -I../include -L../src -lhello

./main

2、 Using llvm bolt instrument binary,

./../../../../build/bin/llvm-bolt ./libhello.so -instrument -instrumentation-file=./hello.fdata -use-old-text -instrumentation-sleep-time=30 -o ./libhello.inst

mv libhello.inst libhello.so
./main

the so occur segment fault, can anyone know the reason? is current bolt dont support dynamic instrument ?

[ccx1225]

but i use in Executable bin, is OK, the dynamic lib is error

[maksfb]

We currently lack the support for instrumenting shared libraries. At the very minimum we should give an error during the instrumentation time. Thanks for reporting.

[ccx1225]

how could i get the bolt support shared libraries,  just coding by myself?

…

---Original--- From: ***@***.***> Date: Sat, Apr 3, 2021 02:12 AM To: ***@***.***>; Cc: ***@***.******@***.***>; Subject: Re: [facebookincubator/BOLT] Using Bolt in dynamic libary, occur Segmentation fault (#137) We currently lack the support for instrumenting shared libraries. At the very minimum we should give an error during the instrumentation time. Thanks for reporting. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[undingen]

I run into the same issue :(.
Could you please describe whats missing: Is it just a case of having to call some initialization functions to the bolt runtime from the shared object or is adding support a larger task?
Unfortunately I'm using a AMD Ryzen cpu so can't use perf to get a profile :/.

[rafaelauler]

It's a bit more complicated. Helper code dealing with instrumentation lives in a static library, a .a file with object files .o. We open this archive and link this .o file with RuntimeDyld (an LLVM just-in-time loader). This is straightforward for non-PIC code.

But position independent code, used in shared libraries, requires a bit more. The linker needs to create indirection tables (GOT and PLT) whenever the code references an exported symbol. This means that if we change our build rules to link the runtime library (containing instrumentation code) as a shared lib (.so), we need to write code to merge it into the input .so correctly. Perhaps it's just a matter of copying input sections of the runtime .so to the input .so. Perhaps it will require merging some sections. I can't tell if there is a good strategy to do this easily.

So if you are relying on AMD Ryzen but you somehow have access to a single Intel machine, what you can do is to just collect the profile on an Intel machine, and use the profile on AMD.

[vleonen]

@ccx1225 @undingen Please check if the issue is solved in the recent Bolt version (main branch, after commits from MR#192 were cherry-picked).

[ccx1225]

@vleonen ， thank you. It is OK

[yota9]

@rafaelauler I think we can close this?

[kmod]

We're still having an issue with running bolt on a shared object -- it no longer crashes during the build process, but the resulting shared object has different behavior. We haven't had time to track it down, but if it helps we can post the raw files.

[yota9]

Sure @kmod we can try to figure out what is happening, please give us the example which we can use to reproduce the problem

[undingen]

I work together with @kmod on pyston and took a look at the issue:
It comes down to -instrument setting -jump-tables=move internally which generates invalidate code for our main interpreter loop (very complicated function using computed gotos etc) which we already track in #175. Skipping this functions makes instrumenting on the shared object work - thanks for your team implementing this! will make development much easier for me and my amd cpu.

[rafaelauler]

Sounds good, then I'll close this one and leave 175 open. Thanks folks!