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

[John McCall via llvm-dev]

On 22 Sep 2020, at 16:55, Leonard Chan wrote:
> I see. So we can extend this to accept global constant variables. On
> platforms that support it, we can lower to a GOT reference. I'm not sure
> what a generic case could be for other targets, but I guess we could
> explicitly leave it to the backend to decide by using the `VK_GOTPCREL`
> variant kind (`MCSymbolRefExpr::create(Symbol,
> MCSymbolRefExpr::VK_GOTPCREL, Ctx)`), which in the end may even use a GOT
> reference. I think this should still respect having a link-time constant
> offset and represent an insignificant address.
>
> Using `dso_local_equivalent` sounds like a good idea. It looks like this
> could also be used by the RTTI component for the vtable. Right now the
> relative vtables ABI uses a proxy dso_local global for the RTTI component
> that just points to the original RTTI global, but accessing that global
> requires an extra indirection. For now I'd like to just implement support
> for functions, but can work on global constants afterwards.

Yes, I think that’s reasonable.  The global-variable case is more
complicated and in its full generality would have to depend on unportable
features like copy relocations.

John.

>
> On Thu, Sep 17, 2020 at 10:30 PM John McCall <rjmccall at apple.com> wrote:
>
>> On 17 Sep 2020, at 18:00, Leonard Chan via llvm-dev wrote:
>>
>> On Mon, Aug 31, 2020 at 2:22 PM James Y Knight <jyknight at google.com>
>> wrote:
>>
>> IIUC, the actual requirements for the proposed pltentry(@X) constant is:
>> 1. The returned address MUST have a constant offset at link-time from
>> some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which
>> symbol it is is presumed not to matter because all locally-defined symbols
>> have constant offsets from each-other, anyhow.
>> 2. The address is otherwise insignificant. (Therefore, coming up with a
>> brand new unique address, by creating a local stub function, would be an
>> acceptable implementation.)
>>
>> These requirements do seem somewhat generic: even on a system which has a
>> different way to make a call could still create a local stub function, and
>> give you the address of that. However, "unnamed address" isn't a good
>> name, because it doesn't capture the first requirement, only the second.
>>
>> I generally agree with Chris that it’d be nice to move towards being
>> able to represent target-specific relocations. That said, in this
>> specific case I completely agree with James: this is a portable
>> concept that shouldn’t be relegated to a bunch of target-specific
>> relocations. There’s no actual requirement that the function be the
>> one generated for PLT import; it just needs to be a function that’s
>> semantically equivalent to another.
>>
>> Hi all. Are there any thoughts on the new name idea ("dso_local_stub" or
>> "dso_local_unnamed_stub")? I'd like to see if I can move forward with my
>> patch.
>>
>> There’s an interesting related idea here of emitting a reference to
>> a GOT entry. We do this in Swift by just emitting an unnamed_addr
>> private constant global variable that’s initialized to a particular
>> symbol, and the backend is typically clever enough to recognize the
>> pattern and use the relocations for a GOT entry. That is similarly
>> a portable concept: at worst, a backend can just make a normal global
>> variable. So at the very least, that’s something to consider in your
>> design.
>>
>> We could try to apply that same approach to stubs. Pattern-matching
>> a short function body might be a lot to ask (and can’t always be done
>> if e.g. there are varargs or inalloca arguments), but we could just
>> set something on a Function that says it’s defined to be semantically
>> equivalent to some other Function. This would also support cases
>> like when two different symbols have to be exported but they’re known
>> to have the same effect. This can be done today with aliases, but
>> there are actually a lot of tricky object-file and linker restrictions
>> on aliases, and it would be nice if the frontend could just say
>> “this function has the same semantics as this other one” and let the
>> backend figure out whether an alias is possible or if it requires a
>> stub.
>>
>> One virtue of making a new kind of Constant is that it’s naturally
>> a lot easier to test, though. For example, a v-table initializer
>> would just be a sequence of dso_local_stubs of functions. With
>> an alias-stub, the v-table initializer itself would just have a
>> sequence of fake functions, which you’d then have to separately test
>> to make sure they had the right equivalency link to the true target.
>>
>> I’m wondering if it’s an issue that the name dso_local_stub is
>> specific to functions. The basic concept of “give me something
>> equivalent to this” also works for variables. Now, obviously there
>> are a ton of cases where it doesn’t work *semantically* for
>> variables:
>> - if the variable is mutable
>> - if the variable’s address is important
>> - if you don’t know the variable’s contents statically (unless the
>> loader supports something like a copy relocation, and you do at
>> least know the variable’s size)
>> But there are still cases where those things don’t hold: maybe
>> there’s some shared constant structure you’d like to use (like a
>> v-table), and you’d prefer to use the same copy as other people,
>> but only if it doesn’t require extra dynamic linking. If
>> you wanted to leave room for that kind of thing, you could use
>> the name dso_local_equivalent.
>>
>> John.
>>