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

[Fāng-ruì Sòng via llvm-dev]

On Fri, Aug 21, 2020 at 3:32 PM Eli Friedman <efriedma at quicinc.com> wrote:
>
> > -----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.

Agree.

> 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

A new subclass of GlobalIndirectSymbol? Looks fine. Do you think the
name "plt" should be moved from the name of the subclass to an
argument of the syntax (like alias/ifunc)?

> > 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.