cc @Gabriel Majeri Hi!
so I've looked around and realized the symbols which use the PLT are generated by LLVM code
to begin with, could you give me an idea how to make
x.py rebuild the local LLVM if I've made a change?
I remember needing to actually stage the LLVM submodule changes so that
x.py did not check-out the previous version
I recall there possibly being some flag(s) to make x.py not checkout submodules for you, but I don’t remember what they are.
LLVM making calls to @PLT seems plausible. This ties back into what I had suggested before: changing the
yeah, that's the one.
hmm, well I set that to false, and even comitted my changes to the submodule and it seems like it doesn't work
I'd rather not do a clean rebuild of LLVM if possible
In that case you could
src/rustllvm/llvm-rebuild-trigger, but I can’t immediatelly tell if it rebuilds from scratch or not
lemme try it for you
nevermind, I've deleted
llvm-finished-building file and it works now
/me will try nevertheless, out of sheer interest
Yeah, it seems like touching
llvm-rebuild-trigger does not help.
You need to remove the llvm-finished-building markerfile
@Gabriel Majeri the appropriate location to set flags for llvm build is in
LLVM was already built with
-fno-plt for me, because I set
CXXFLAGS=-fno-plt and it picked that up
Something even weirder is going on here. I've completly removed the code to call functions through PLT from LLVM and it _still_ generates some PLT calls
Literally, at this point even if I build with
-Z plt=yes, LLVM should simply not know how to generate PLT calls, yet for some compiler intrinsics it still seems to generate them
Can you get a list of all @PLTd symbols at all?
OK, so for a simple
hello world binary, the functions which use the PLT are:
These are all intrinsic functions, generated by LLVM implicitly
I added the
RtLibUseGOT module flag to all Rust modules to ensure LLVM doesn't use the PLT for these calls, but it seems it didn't work?
OK, so for a simple
hello worldbinary, the functions which use the PLT are:
At least some of those are provided by glibc, is it possible that calling function at all would require calling through @PLT?
No, that's the issue, on my Arch distro where every C binary is compiled with
-fno-plt, there are absolutely no PLT mentions in the disassembly. I want to get Rust binaries to the same point.
Okay. So they cannot come from the standard library and
__stack_chk_fail is definitely called by LLVM itself, yeah.
I’m honestly not sure where in LLVM @PLT calls are generated, so my guess is as good as yours. But I expected there to be more calls in the first place.
if it is just those, that’s already very workable :slight_smile:
Yeah, I am happy to say that we got rid of 80-90% of the PLT calls. When the perf run was made, we had only gotten rid of 20% of the calls, so perf should be even better once it gets merged
lets run perf again, I guess.
I wanted to see if we can get rid of ALL the PLT calls before trying that
Feel free to keep trying. Whenever you’re ready just ping me and I’ll kick the perf off
Well I seem to be getting somewhere. It seems
libbacktrace's build file didn't take into account global CFLAGS, so after adding
-fno-plt I managed to at least eliminate the
I'll investigate the other calls, but it seems the story will be similar: C libraries (which don't respect CFLAGS) are the issue
At least calls to
__stack_chk_fail@PLT are entirely generated by LLVM
@Gabriel Majeri you could just grep through disassembly of the whole binary for
call .*@PLT to see what calls via PLT.
Oh lovely, it seems
jemalloc is also betraying us.
Using the system allocator drastically reduces the number of PLT calls
Also, it seems
jemalloc recorded the
-fno-plt flag in the
SPECIFIED_CFLAGS Makefile variable, but then decided to ignore it when building
Well I don't think there's much more I can do here. The issue is with C code, and the best solution I guess is to eventually rewrite everything in Rust :)
Well I don't think there's much more I can do here. The issue is with C code, and the best solution I guess is to eventually rewrite everything in Rust :slight_smile:
I’m starting another perf run then