<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Mar 11, 2016 at 9:56 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Mar 11, 2016 at 9:41 AM, John McCall <span dir="ltr"><<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</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"><div style="word-wrap:break-word"><div>Okay, so, it sounds to me like LLVM basically treats strong definitions as protected, then.  Should we just formalize that?</div><div><br></div><div>I guess the proposal here would be:</div><div>  1. Remove protected visibility from LLVM.  (Or deprecate it as equivalent to default.)</div><div>  2. Teach the ELF emitter to emit non-hidden strong definitions using ELF protected visibility.</div><div>  3. Teach the ELF emitter to emit non-hidden weak definitions using ELF default visibility (unless they’re unnamed_addr?).</div></div></blockquote><div><br></div></span><div>LLVM definitely thinks that strong definitions are "ODR", so we could do 2. I'm sure it would break somebody, somewhere though. We probably don't want to do 1 and 3, so that users can still mark their weak definitions as protected if they want to.</div></div></div></div></blockquote><div><br></div><div>Yes, but what I think John was getting at with 3 could work (modulo possible breakage, as you mention): "Teach the ELF emitter to emit non-hidden weak unnamed_addr definitions using ELF protected visibility".</div><div><br></div><div>Thanks,</div></div><div class="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>