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

[Fangrui Song via llvm-dev]

On 2020-08-20, Eric Christopher via llvm-dev wrote:
>I do have concerns about the amount of object level modeling that we want
>to do in the IR though. While it isn't the highest level IR we've managed
>to mostly avoid these kinds of features/complications in the past. I'm
>definitely interested in hearing some alternate implementations here and
>there rather than a full set of constants for relocations. Keeping the IR
>abstract enough over the object file level other than in generalizable
>cases still feels like a win.
>
>-eric
>
>On Thu, Aug 20, 2020 at 8:44 PM Chris Lattner via llvm-dev <
>llvm-dev at lists.llvm.org> wrote:
>
>> Hi Leonard,
>>
>> I haven’t looked at your patch in detail, but I think that this is a step
>> in the right direction.  I would like to see new “Constant*”’s that
>> directly map onto the relocations that various object formats use (for
>> example, macho has a relocation for “&g1-&g2+cst”).  This would get us to a
>> more principled lowering in many cases as well as make the backend modeling
>> more specific.
>>
>> -Chris
>>
>> On Aug 20, 2020, at 11:29 AM, Leonard Chan via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>
>> Hi all,
>>
>> We would like to propose a new Constant type in LLVM for representing
>> entries in the Procedure Linkage Table (PLT).
>>
>> The PLT is a data structure used for dispatching position-independent
>> function calls to appropriate functions where the address of the function
>> is not known statically. Right now, if a call is made to a function, it may
>> be lowered to a direct call to the function itself or the PLT entry for
>> that function. LLVM has checks that dictate if the function call should be
>> a direct reference or PLT entry, but we don’t have a way in IR to
>> semantically represent that the PLT entry should be used.
>>
>> The proposed constant would be analogous to BlockAddress, but instead
>> represent the PLT entry for functions. The usage could look something like:
>>
>> pltentry(@function)
>>
>> and would always have the same type as the function. A pltentry would
>> operate exactly like a function, but the main difference is that it’s
>> lowered to the PLT entry (function at plt) on targets that support PLT
>> relocations. The linker can then decide if it should be relaxed into a
>> direct reference or remain a PLT entry.
>>
>> I have a very rough WIP implementation at https://reviews.llvm.org/D77248.
>>
>> Thoughts and opinions?
>>
>> Thanks,
>> Leonard

Note that there is some terminology misnomer or concept confusion here.

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

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.

> The compiler should not assume that a Function will be lowered to the
> PLT entry for it, so we can use this instead to semantically
> represent in LLVM that a PLT should be used.

The "PLT entry" part of the sentence is not entirely correct.