Stream: t-compiler

Topic: disable .got section in ELF object file


Kevin Boos (Nov 27 2018 at 18:53, on Zulip):

(First time using zulip, I was directed here by @nagisa from #rustc IRC, so lmk if I've done something wrong. )

How do I instruct rustc to not emit code that uses GOT-based relocations?

I have a large OS project that was previously using rustc 1.27.0, and by using the code-model=large, I was able to get it to never emit GOT-based relocations, and there wasn't even a .got or .got.plt section. I don't want the object file to contain any relocation entries like R_X86_64_GOTPC64, R_X86_64_GOT64, R_X86_64_GOTOFF64.
I just upgraded to rustc 1.32.0 and it now uses the .got no matter what I do. Disabling pic, pie, or plt don't seem to be doing the trick. Any tips?

Thanks!

nagisa (Nov 27 2018 at 19:02, on Zulip):

Do you know what symbols do emit these relocations?

nagisa (Nov 27 2018 at 19:02, on Zulip):

Also are you specifying -Crelocation-model=static?

Kevin Boos (Nov 27 2018 at 19:07, on Zulip):

looking at the output of readelf, it appears that every symbol is now using a GOT-based relocation type

Kevin Boos (Nov 27 2018 at 19:08, on Zulip):

i wasn't using a static relocation model, no.

nagisa (Nov 27 2018 at 19:17, on Zulip):

… does it work with static relocation model?

Kevin Boos (Nov 27 2018 at 19:18, on Zulip):

Just tried the static relocation model -- it does indeed remove the .got section, but then it also causes other symbols to be absent from other crates' object files.
The issue here is that I'm dynamically loading & linking many object files (one obj file per crate in my project), and the static relocation model seems to cause some symbols to no longer be present in those object files. I'm looking into it now.

Kevin Boos (Nov 27 2018 at 19:18, on Zulip):

is there somewhere i can read more about the static relocation model? I didn't need to specify that before, when using rustc 1.27.0

nagisa (Nov 27 2018 at 19:20, on Zulip):

static relocation model is exactly what it says on the tin: it generates code without any relocations (what GOT is). The default model is not static, so it seems more like an accident/lucky coincidence that it did what you expected before

Kevin Boos (Nov 27 2018 at 19:21, on Zulip):

i see, thanks. Yeah, it may have been a lucky coincidence before.

Kevin Boos (Nov 27 2018 at 19:23, on Zulip):

Does the static relocation model only allow global/absolute address relocation types, or does it still allow PC-relative relocation types to be used? My previous object files on 1.27.0 contained PC-relative relo types, but I don't seen any now.

nagisa (Nov 27 2018 at 19:25, on Zulip):

honestly, not sure :slight_smile:

nagisa (Nov 27 2018 at 19:25, on Zulip):

you might want to try other options from -Crelocation-model=help as well to see if the stuff starts working with any of them

Kevin Boos (Nov 27 2018 at 19:26, on Zulip):

ok, np. I did try a variety of relocation models yesterday, but they didn't seem to work. I'll go back and review them further.
Thanks a lot in any case!

Kevin Boos (Nov 27 2018 at 19:37, on Zulip):

I wonder if some LLVM change caused the large code model option to no longer take precedence over the PIC relocation model option. From the docs, I would expect that if the large code model option was given, then LLVM would be forced to use absolute relo types because it can't assume that relo sources are nearby the target PC....

nagisa (Nov 27 2018 at 19:51, on Zulip):

code model and relocation model are two independent options

Kevin Boos (Nov 27 2018 at 19:55, on Zulip):

ah, ok, in that case it's probably down to what you suggested before, a lucky coincidence in which specifying only the large code model resulted in no GOT-based relo entries.

Last update: Nov 22 2019 at 05:35UTC