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

[Peter Collingbourne via llvm-dev]

On Fri, Aug 21, 2020 at 4:04 PM Fāng-ruì Sòng via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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)?
>

I don't think this is a good idea. GlobalValues are meant to represent
"symbols", and a PLT entry is not a symbol. Furthermore, this would be a
special type of GlobalIndirectSymbol that would not require the referent to
be defined (as GlobalAlias and GlobalIFunc do). So I don't see this fitting
smoothly into existing code, in fact I suspect that more code would need to
be adjusted to handle PLT entries as a special case than if we just made it
a Constant.

Fundamentally this is more similar to ConstantExpr than anything under
GlobalValue, but since the operand is required to be a GlobalValue and
there would be no corresponding Instruction, the right place to put it is
under Constant IMHO.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200821/eb4e2fbf/attachment.html>