<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 23, 2017 at 9:10 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Peter Collingbourne via Phabricator <<a href="mailto:reviews@reviews.llvm.org" target="_blank">reviews@reviews.llvm.org</a>> writes:<br>
<br>
> pcc created this revision.<br>
> Herald added a subscriber: mehdi_amini.<br>
><br>
> dllexport is not actually a global-level attribute. At the object file<br>
> level, it is in fact a module-level attribute and is represented with an<br>
> /export flag in the directive section. Trying to shoehorn it into being a<br>
> global-level attribute creates unnecessary complexity and a burden on the<br>
> rest of the compiler and invites bugs.<br>
<br>
</span>But that directive is a list, so in this regard they seem equivalent.<br>
<br>
In PR32334 I see:<br>
<br>
------------------------------<wbr>------------------------------<br>
In COFF, exports are identified by a list of /export flags in the<br>
.drective section, so when a comdat section is discarded, we don't lose<br>
the information that the symbol might be exported.<br>
------------------------------<wbr>------------------------------<wbr>-----<br>
<br>
Which is the case where the two representations are different. Even if<br>
we drop the last IR @foo, we still need to remember that @foo is to be<br>
exported.</blockquote><div><br></div><div>Indeed. I will update the commit message to make that clearer. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> Independent of whether it is a global- or module-level attribute, it makes<br>
> sense to split dllimport from dllexport, as they are somewhat orthogonal. The<br>
> meaning of dllexport is similar to ELF symbol visibility, while the meaning<br>
> of dllimport is closer to preemptability (see also<br>
> <a href="https://reviews.llvm.org/D20217" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2021<wbr>7</a>).<br>
<br>
</span>I agree. dllexport is almost redundant. Using ELF terminology we can say<br>
that COFF systems just default to hidden visibility and have the option<br>
of using protected when they want to export a symbol. The analogy is not<br>
exact in that ELF visibilities are merged by taking the minimum.<br></blockquote><div><br></div><div>Right. In principle we have an analogous situation in ELF: the IR may contain a declaration such as:</div><div><br></div><div>declare hidden void @foo()</div><div><br></div><div>and that could have an effect on foo's visibility (assuming it is >hidden) depending on whether the foo declaration was dropped.</div><div><br></div><div>I think the solution is to think of a non-defining declaration's visibility as an ODR-relevant property (i.e. if you specify a non-default visibility, it has to agree with the prevailing definition). As PR32334 shows, dllexport cannot be relied on as an ODR property in COFF.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
> With this,<br>
> dllimport can potentially receive a meaning in other object formats without<br>
> being in the confusing situation where dllexport only has meaning for COFF<br>
> and dllimport also has meaning elsewhere.<br>
<br>
</span>I would love to use dllimport on ELF to mean "assume this symbol is<br>
external regardless of -fPIC".<br>
<span><br>
> This patch does three things:<br>
><br>
> - Moves the linker options from a module flag to top-level module metadata. Storing it as a module flag only makes it harder to manipulate the linker options.<br>
> - Causes clang to add an /export flag to the linker options metadata if it is emitting a definition that will be dllexported.<br>
> - Removes the dllexport storage class and stores dllimport as a boolean.<br>
<br>
</span>I love this change :-)<br>
<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-4633559366597390973gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>