[llvm-dev] [RFC][LLVM] New Constant type for representing function PLT entries

Eli Friedman via llvm-dev llvm-dev at lists.llvm.org
Fri Aug 21 14:53:35 PDT 2020


> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Fangrui
> Song via llvm-dev
> Sent: Thursday, August 20, 2020 10:18 PM
> To: Leonard Chan <leonardchan at google.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>
> Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for
> representing function PLT entries
>
> A @plt modifer (x86-32, x86-64 and aarch64) in assembly refers to a
> function whose address can be insignificant. The assembler produces an
> R_386_PLT32/R_X86_64_PLT32/R_AARCH64_PLT32 relocation which will be
> resolved by the linker to either:
>
> * the definition (non-preemptible (logical AND (non-ifunc or ld.lld -z ifunc-
> noplt is specified)))
> * a PLT entry (other cases)
>
> The address can be insignificant: ultimately the program will call the
> function. There is no difference if the program calls the function
> directly or calls through one PLT entry in any module (executable or a
> shared object).
>
> R_386_PC32/R_X86_64_PC32/R_AARCH64_PREL32

Ignoring the ELF-specific bits, in essence, it's some dso-local function that's functionally equivalent to the actual resolved function at runtime.  The address may or may not be equal to that of the resolved function.

Maybe it would make sense to introduce a GlobalValue to represent this, along the lines of GlobalIFunc?  I guess the end result isn't a lot different from the original proposal: you still end up with a Constant that represents the PLT entry.  But I think it would fit more smoothly into existing optimizations that understand GlobalValues.  And it would make it clear that importing one from another IR module might be a non-trivial operation.  (I don't think we actually do cross-DSO optimizations at the moment, but it's not outside the realm of possibility.)

-Eli

> The proposd 'pltentry' syntax is an IR level concept to lower the
> address of constant to use the @plt modifier.
>
> A Procedure Linkage Table (PLT) entry may or may not be created by the
> linker - if it is not necessary, the linker will not create it.  I think
> we do need some way to represent this in IR, but I hope we can find a
> better name for this concept. Many will think "PLT is a pure linker
> synthesized entry - why do we bother calling some compiler-generated
> stuff PLT". The @plt assembly syntax is a bit unfortunate as well - I
> suggested it anyway in https://reviews.llvm.org/D81184 because its x86
> counterpart had used this concept for many years.


More information about the llvm-dev mailing list