(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.plt section. I don't want the object file to contain any relocation entries like
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?
Do you know what symbols do emit these relocations?
Also are you specifying
looking at the output of
readelf, it appears that every symbol is now using a GOT-based relocation type
i wasn't using a static relocation model, no.
… does it work with static relocation model?
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.
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
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
i see, thanks. Yeah, it may have been a lucky coincidence before.
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.
honestly, not sure :slight_smile:
you might want to try other options from
-Crelocation-model=help as well to see if the stuff starts working with any of them
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!
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....
code model and relocation model are two independent options
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.