Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
x86: Treat R_386_PLT32 as R_386_PC32
This is similar to commit b21ebf2 "x86: Treat R_X86_64_PLT32 as R_X86_64_PC32", but for i386. As far as Linux kernel is concerned, R_386_PLT32 can be treated the same as R_386_PC32. R_386_PC32/R_X86_64_PC32 are PC-relative relocation types with the requirement that the symbol address is significant. R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types without the address significance requirement. On x86-64, there is no PIC vs non-PIC PLT distinction and an R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and `call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. On i386, there are 2 types of PLTs, PIC and non-PIC. Currently the convention is to use R_386_PC32 for non-PIC PLT and R_386_PLT32 for PIC PLT, but R_386_PLT32 is arguably preferable for -fno-pic code as well: this can avoid a "canonical PLT entry" (st_shndx=0, st_value!=0) if the symbol turns out to be defined externally. Latest Clang (since 961f31d8ad14c66829991522d73e14b5a96ff6d4) can use R_386_PLT32 for compiler produced symbols (if we drop -ffreestanding for CONFIG_X86_32, library call optimization can produce newer declarations) and future GCC may use R_386_PLT32 as well if the maintainers agree to adopt an option like -fdirect-access-external-data to avoid "canonical PLT entry"/copy relocations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112 Link: ClangBuiltLinux#1210 Reported-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Fangrui Song <maskray@google.com>
- Loading branch information