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

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

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.

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>

> -----Original Message-----
> From: Fāng-ruì Sòng <maskray at google.com>
> Sent: Friday, August 21, 2020 4:04 PM
> To: Eli Friedman <efriedma at quicinc.com>
> Cc: Leonard Chan <leonardchan at google.com>; llvm-dev at
lists.llvm.org
> Subject: [EXT] Re: [llvm-dev] [RFC][LLVM] New Constant type for
> representing function PLT entries
>
> 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
> > >
> > 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.)
> >
> 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 IR concept could be generalized so it doesn't actually depend on the
object format having a PLT.  For example, it could be used to refer to an import
thunk on Windows.  So I'm not sure we want to name the IR concept after a
"PLT".

LLVM IR currently has the dso_local concept, so maybe we want to leverage that
in the name. Maybe something like GlobalDSOLocalFunc?  (Not sure I'm really
happy with that exact name, but hopefully the idea makes sense.)

-Eli