<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<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 #777; color:#777; margin:0 0 5px; padding-left:5px"><blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On Mon, Aug 31, 2020 at 2:22 PM James Y Knight <jyknight@google.com><br>
wrote:<br>
</p>
<blockquote style="border-left:2px solid #777; color:#BBB; margin:0 0 5px; padding-left:5px; border-left-color:#BBB"><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 #777; color:#777; margin:0 0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">inalloca</code> arguments), but we could just<br>
set something on a <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">Function</code> that says it’s defined to be semantically<br>
equivalent to some other <code style="background-color:#F7F7F7; border-radius:3px; margin:0; padding:0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 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:#F7F7F7; border-radius:3px; margin:0; padding:0 0.4em" bgcolor="#F7F7F7">dso_local_equivalent</code>.</p>
<p dir="auto">John.</p>
</div>
</div>
</body>
</html>