<div dir="ltr">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.<div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 10:30 PM John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal">
<p dir="auto">On 17 Sep 2020, at 18:00, Leonard Chan via llvm-dev wrote:</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><blockquote style="border-left:2px solid rgb(153,153,153);color:rgb(153,153,153);margin:0px 0px 5px;padding-left:5px"><p dir="auto">On Mon, Aug 31, 2020 at 2:22 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>><br>
wrote:<br>
</p>
<blockquote style="border-left:2px solid rgb(187,187,187);color:rgb(187,187,187);margin:0px 0px 5px;padding-left:5px"><p dir="auto">IIUC, the actual requirements for the proposed pltentry(@X) constant is:<br>
1. The returned address MUST have a constant offset at link-time from<br>
some other unspecified but defined-in-the-same-binary/DSO symbol Y. Which<br>
symbol it is is presumed not to matter because all locally-defined symbols<br>
have constant offsets from each-other, anyhow.<br>
2. The address is otherwise insignificant. (Therefore, coming up with a<br>
brand new unique address, by creating a local stub function, would be an<br>
acceptable implementation.)<br>
<br>
These requirements do seem somewhat generic: even on a system which has a<br>
different way to make a call could still create a local stub function, and<br>
give you the address of that. However, "unnamed address" isn't a good<br>
name, because it doesn't capture the first requirement, only the second.</p>
</blockquote></blockquote></blockquote></div>
<div style="white-space:normal">

<p dir="auto">I generally agree with Chris that it’d be nice to move towards being<br>
able to represent target-specific relocations.  That said, in this<br>
specific case I completely agree with James: this is a portable<br>
concept that shouldn’t be relegated to a bunch of target-specific<br>
relocations.  There’s no actual requirement that the function be the<br>
one generated for PLT import; it just needs to be a function that’s<br>
semantically equivalent to another.</p>

</div>
<div style="white-space:normal"><blockquote style="border-left:2px solid rgb(119,119,119);color:rgb(119,119,119);margin:0px 0px 5px;padding-left:5px"><p dir="auto">Hi all. Are there any thoughts on the new name idea ("dso_local_stub" or<br>
"dso_local_unnamed_stub")? I'd like to see if I can move forward with my<br>
patch.</p>
</blockquote></div>
<div style="white-space:normal">

<p dir="auto">There’s an interesting related idea here of emitting a reference to<br>
a GOT entry.  We do this in Swift by just emitting an <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">unnamed_addr</code><br>
private constant global variable that’s initialized to a particular<br>
symbol, and the backend is typically clever enough to recognize the<br>
pattern and use the relocations for a GOT entry.  That is similarly<br>
a portable concept: at worst, a backend can just make a normal global<br>
variable.  So at the very least, that’s something to consider in your<br>
design.</p>

<p dir="auto">We could try to apply that same approach to stubs.  Pattern-matching<br>
a short function body might be a lot to ask (and can’t always be done<br>
if e.g. there are varargs or <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">inalloca</code> arguments), but we could just<br>
set something on a <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">Function</code> that says it’s defined to be semantically<br>
equivalent to some other <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">Function</code>.  This would also support cases<br>
like when two different symbols have to be exported but they’re known<br>
to have the same effect.  This can be done today with aliases, but<br>
there are actually a lot of tricky object-file and linker restrictions<br>
on aliases, and it would be nice if the frontend could just say<br>
“this function has the same semantics as this other one” and let the<br>
backend figure out whether an alias is possible or if it requires a<br>
stub.</p>

<p dir="auto">One virtue of making a new kind of <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">Constant</code> is that it’s naturally<br>
a lot easier to test, though.  For example, a v-table initializer<br>
would just be a sequence of <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">dso_local_stub</code>s of functions.  With<br>
an alias-stub, the v-table initializer itself would just have a<br>
sequence of fake functions, which you’d then have to separately test<br>
to make sure they had the right equivalency link to the true target.</p>

<p dir="auto">I’m wondering if it’s an issue that the name <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">dso_local_stub</code> is<br>
specific to functions.  The basic concept of “give me something<br>
equivalent to this” also works for variables.  Now, obviously there<br>
are a ton of cases where it doesn’t work <em>semantically</em> for<br>
variables:<br>
- if the variable is mutable<br>
- if the variable’s address is important<br>
- if you don’t know the variable’s contents statically (unless the<br>
  loader supports something like a copy relocation, and you do at<br>
  least know the variable’s size)<br>
But there are still cases where those things don’t hold: maybe<br>
there’s some shared constant structure you’d like to use (like a<br>
v-table), and you’d prefer to use the same copy as other people,<br>
but only if it doesn’t require extra dynamic linking.  If<br>
you wanted to leave room for that kind of thing, you could use<br>
the name <code style="background-color:rgb(247,247,247);border-radius:3px;margin:0px;padding:0px 0.4em" bgcolor="#F7F7F7">dso_local_equivalent</code>.</p>

<p dir="auto">John.</p>
</div>
</div>
</div>

</blockquote></div>