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

[John McCall via llvm-dev]

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_stub`s 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200918/df376efd/attachment.html>