<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Mar 7, 2016, at 4:22 PM, Peter Collingbourne <<a href="mailto:peter@pcc.me.uk" class="">peter@pcc.me.uk</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 7, 2016 at 4:09 PM, John McCall <span dir="ltr" class=""><<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2016, at 2:48 PM, Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Mon, Feb 29, 2016 at 1:53 PM, <span dir="ltr" class=""><<a class=""></a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
@A_vtable = {i8*, i8*, i32, i32} {0, @A::rtti, @A::f - (@A_vtable + 16), @A::g - (@A_vtable + 16)}<br class=""></blockquote><div class=""><br class=""></div><div class="">There's a subtlety about this aspect of the ABI that I should call attention to. The virtual function references can only be resolved directly by the static linker if they are defined in the same executable/DSO as the virtual table. I expect this to be the overwhelmingly common case, as classes are normally wholly defined within a single executable or DSO, so our implementation should be optimized around that case.</div><div class=""><br class=""></div><div class="">If we expected cross-DSO references to be relatively common, we could make vtable entries be relative to GOT entries, but that would introduce an additional level of indirection and additional relocations, probably costing us more in binary size and memory bandwidth than the current ABI.<br class=""></div><div class=""><br class=""></div><div class="">However, it is technically possible to split the implementation of a class's virtual functions between DSOs, and there are more practical cases where we might expect to see cross-DSO references:</div><div class=""><br class=""></div><div class=""><div class="">- one DSO could derive from a class defined in another DSO, and only override some of its virtual functions</div></div><div class="">- the vtable could contain a reference to __cxa_pure_virtual which would be defined by the standard library</div><div class=""><br class=""></div><div class="">We can handle these cases by having the vtable refer to a PLT entry for each function that is not defined within the module. This can be done by using a specific type of relative relocation that refers directly to the symbol if defined within the current module, or to a PLT entry if not. This is the same type of relocation that is needed to implement relative branches on x86, so I'd expect it to be generally available on that architecture (ELF has R_{386,X86_64}_PLT32, Mach-O has X86_64_RELOC_BRANCH, COFF has IMAGE_REL_{AMD64,I386}_REL32, which may resolve to a thunk [1], which is essentially the same thing as a PLT entry). It is also present on ARM (R_ARM_PREL31, which was apparently added to support unwind tables).</div><div class=""><br class=""></div><div class="">We still need some way to create PLT relocations in the vtable's initializer without breaking the semantics of a load from the vtable. Rafael and I discussed this and we believe that if the target function is unnamed_addr, this indicates that the function's address isn't observable (this is true for virtual functions, as it isn't possible to take their address), and so it could be substituted with the address of a PLT entry.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span>This seems like the best way to handle it.</div><div class=""><br class=""></div><div class="">It would be nice if this could be requested of an arbitrary function without having to rely on it being unnamed_addr — that is, it would be nice to have “the address of an unnamed_addr function in this linkage unit which is equivalent when called to this other function that’s not necessary within this linkage unit”. It's easy to make an unnamed_addr wrapper function, and maybe we could teach the backend to peephole that to a PLT function reference, but (1) that sounds like some serious backend heroics and (2) it wouldn’t work for variadic functions.</div></div></blockquote><div class=""><br class=""></div><div class="">Yes, that seems like far too much for what is needed here.</div></div></div></div></div></blockquote><div><br class=""></div>It’s a shame, though. We play a similar trick with GOT entries, and it ends up being quite elegant, at least in IR. I think there are similar problems with trying to eliminate the fake symbol in the backend, though.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">One complication is that on ELF the linker will still create a PLT entry if the symbol has default visibility, in order to support symbol interposition. We can mitigate against that by using protected visibility for virtual functions if they would otherwise receive default visibility.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span>To clarify, this is just a performance problem and doesn’t actually break semantics or feasibility, right?</div></div></blockquote><div class=""><br class=""></div><div class="">Performance and code size (I suspect that all the extra PLT entries would negate most of the binary size savings associated with the relative ABI). It doesn't break semantics of regular C++ programs, as long as you stick to the ODR. It can only break things if a program relies on ELF symbol interposition to replace a DSO's implementation of a virtual function with something else (which I can't really imagine being very common at all, given that ELF is the only object format that could support this). I think the right response to that is "sorry, if you need symbol interposition, then go use the platform ABI”.</div></div></div></div></div></blockquote><div><br class=""></div></div>I mean, I’ve never really liked ELF’s stance on symbol interposition, but taking it as given, I’m not sure I agree that it’s reasonable to carve out virtual functions as a general exception.<div class=""><br class=""></div><div class="">Isn’t there some global flag to make (non-weak?) definitions use protected visibility by default? Wouldn’t using that be an overall performance win anyway?<div class=""><br class=""></div><div class="">John.</div></div></body></html>