Stream: t-compiler

Topic: @PLT symbols in rustc code


nagisa (Sep 28 2018 at 13:04, on Zulip):

cc @Gabriel Majeri Hi!

Gabriel Majeri (Sep 28 2018 at 13:05, on Zulip):

so I've looked around and realized the symbols which use the PLT are generated by LLVM code

Gabriel Majeri (Sep 28 2018 at 13:05, on Zulip):

to begin with, could you give me an idea how to make x.py rebuild the local LLVM if I've made a change?

nagisa (Sep 28 2018 at 13:07, on Zulip):

I remember needing to actually stage the LLVM submodule changes so that x.py did not check-out the previous version

nagisa (Sep 28 2018 at 13:08, on Zulip):

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.

nagisa (Sep 28 2018 at 13:08, on Zulip):

LLVM making calls to @PLT seems plausible. This ties back into what I had suggested before: changing the cc crate.

davidtwco (Sep 28 2018 at 13:09, on Zulip):

(submodules? https://github.com/rust-lang/rust/blob/master/config.toml.example#L133)

nagisa (Sep 28 2018 at 13:09, on Zulip):

(submodules? https://github.com/rust-lang/rust/blob/master/config.toml.example#L133)

yeah, that's the one.

Gabriel Majeri (Sep 28 2018 at 13:10, on Zulip):

hmm, well I set that to false, and even comitted my changes to the submodule and it seems like it doesn't work

Gabriel Majeri (Sep 28 2018 at 13:10, on Zulip):

I'd rather not do a clean rebuild of LLVM if possible

nagisa (Sep 28 2018 at 13:11, on Zulip):

In that case you could touch src/rustllvm/llvm-rebuild-trigger, but I can’t immediatelly tell if it rebuilds from scratch or not

nagisa (Sep 28 2018 at 13:11, on Zulip):

lemme try it for you

Gabriel Majeri (Sep 28 2018 at 13:12, on Zulip):

nevermind, I've deleted llvm-finished-building file and it works now

nagisa (Sep 28 2018 at 13:13, on Zulip):

/me will try nevertheless, out of sheer interest

nagisa (Sep 28 2018 at 13:23, on Zulip):

Yeah, it seems like touching llvm-rebuild-trigger does not help.

nagisa (Sep 28 2018 at 13:23, on Zulip):

You need to remove the llvm-finished-building markerfile

nagisa (Sep 28 2018 at 13:24, on Zulip):

@Gabriel Majeri the appropriate location to set flags for llvm build is in src/librustc_llvm/build.rs btw.

Gabriel Majeri (Sep 28 2018 at 13:33, on Zulip):

LLVM was already built with -fno-plt for me, because I set CXXFLAGS=-fno-plt and it picked that up

Gabriel Majeri (Sep 28 2018 at 13:34, on Zulip):

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

Gabriel Majeri (Sep 28 2018 at 13:34, on Zulip):

pasted image

Gabriel Majeri (Sep 28 2018 at 13:35, on Zulip):

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

nagisa (Sep 28 2018 at 13:37, on Zulip):

Can you get a list of all @PLTd symbols at all?

Gabriel Majeri (Sep 28 2018 at 13:39, on Zulip):

OK, so for a simple hello world binary, the functions which use the PLT are: _Unwind_Resume and __stack_chk_fail, memcpy and memset

Gabriel Majeri (Sep 28 2018 at 13:40, on Zulip):

These are all intrinsic functions, generated by LLVM implicitly

Gabriel Majeri (Sep 28 2018 at 13:41, on Zulip):

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?

nagisa (Sep 28 2018 at 13:51, on Zulip):

OK, so for a simple hello world binary, the functions which use the PLT are: _Unwind_Resume and __stack_chk_fail, memcpy and memset

At least some of those are provided by glibc, is it possible that calling function at all would require calling through @PLT?

Gabriel Majeri (Sep 28 2018 at 13:53, on Zulip):

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.

nagisa (Sep 28 2018 at 13:56, on Zulip):

Okay. So they cannot come from the standard library and __stack_chk_fail is definitely called by LLVM itself, yeah.

nagisa (Sep 28 2018 at 13:59, on Zulip):

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.

nagisa (Sep 28 2018 at 13:59, on Zulip):

if it is just those, that’s already very workable :slight_smile:

Gabriel Majeri (Sep 28 2018 at 14:00, on Zulip):

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

nagisa (Sep 28 2018 at 14:00, on Zulip):

lets run perf again, I guess.

Gabriel Majeri (Sep 28 2018 at 14:01, on Zulip):

I wanted to see if we can get rid of ALL the PLT calls before trying that

nagisa (Sep 28 2018 at 14:01, on Zulip):

Feel free to keep trying. Whenever you’re ready just ping me and I’ll kick the perf off

Gabriel Majeri (Sep 28 2018 at 14:42, on Zulip):

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 _Unwind_Resume@PLT calls

Gabriel Majeri (Sep 28 2018 at 14:43, on Zulip):

I'll investigate the other calls, but it seems the story will be similar: C libraries (which don't respect CFLAGS) are the issue

nagisa (Sep 28 2018 at 14:52, on Zulip):

At least calls to __stack_chk_fail@PLT are entirely generated by LLVM

nagisa (Sep 28 2018 at 14:53, on Zulip):

@Gabriel Majeri you could just grep through disassembly of the whole binary for call .*@PLT to see what calls via PLT.

Gabriel Majeri (Sep 28 2018 at 15:00, on Zulip):

Oh lovely, it seems jemalloc is also betraying us.

Gabriel Majeri (Sep 28 2018 at 15:01, on Zulip):

Using the system allocator drastically reduces the number of PLT calls

Gabriel Majeri (Sep 28 2018 at 15:11, on Zulip):

Also, it seems jemalloc recorded the -fno-plt flag in the SPECIFIED_CFLAGS Makefile variable, but then decided to ignore it when building

Gabriel Majeri (Sep 28 2018 at 17:20, on Zulip):

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 :)

nagisa (Sep 28 2018 at 18:30, on Zulip):

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

Last update: Nov 22 2019 at 04:25UTC