<div dir="ltr">Hi David,<div><br></div><div>Thanks for the feedback! I've reverted <span style="font-size:13px">r258665 until I understand this better.</span></div><div><br></div><div><div class="gmail_extra">> The linker considers three sources:<br></div><div class="gmail_extra"><div>> - EXPORTS directives in a .def file given to the linker</div><div>> - The linker's /EXPORT option</div><div>> - Object files carry a special section, .drectve, which contains additional flags that the linker takes under consideration. __declspec(dllexport) is typically implemented by adding a /EXPORT entry for a particular symbol in there (e.g. /EXPORT:_foo).</div><span></span><div class="gmail_quote"><br></div><div class="gmail_quote">Ok.</div><div class="gmail_quote"><br></div><div class="gmail_quote">> > <span style="color:rgb(80,0,80);font-size:13px">(2) Is there any situation where 'SF_Exported' isn't just the inverse of 'SF_Hidden'? Can we get rid of one or the other of those flags?</span></div><span class="im" style="font-size:13px"><div><br></div></span><div style="font-size:13px">> I don't believe so. Normal static functions will have local binding but default visibility. Such a function would be neither hidden nor exported.</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Something feels not-quite-right about this. What are the valid values for visibility? If's only "hidden" and "default" then we should just need one flag for that. If SF_Exported is capturing a derived value, maybe we should just make it a function on the symbol. E.g.:</div><div class="gmail_extra"><br></div><div class="gmail_extra">bool Symbol::isExported() {</div><div class="gmail_extra"> return isGlobal() && !isHidden();</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">Alternatively I've misunderstood the full meaning of SF_Hidden and SF_Exported. I always just read them as "will this symbol appear in the symbol table for a linked DSO". Under that reading, a non-hidden, non-exported symbol doesn't make sense.</div><div class="gmail_extra"><br></div><div class="gmail_extra">> <span style="font-size:13px">I believe readobj already dumps this sort of information out, albeit in object file specific ways.</span><br></div><div class="gmail_extra"><span style="font-size:13px"><br></span></div><div class="gmail_extra">Ok. I eventually need something that shows the generic flag's value, but the output format of the tool can be object specific. For other properties (e.g. "weak") llvm-objdump and llvm-nm suffice, since they query the generic flags to produce their (format specific) output. If "exported" is of interest to people I could add it to one of the generic tools. Otherwise I'll just add it to llvm-rtdyld.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><span style="font-size:13px">- Lang.</span><br></div><div class="gmail_extra"><span style="font-size:13px"><br></span></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote">On Sun, Jan 24, 2016 at 4:16 PM, David Majnemer <span dir="ltr"><<a href="mailto:david.majnemer@gmail.com" target="_blank">david.majnemer@gmail.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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Sun, Jan 24, 2016 at 2:47 PM, Lang Hames via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</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">Hi Rui, Rafael, Kevin, Nick,<div><br></div><div>In r258665 I added a line to set the SF_Exported flag in COFFObjectFile - the JIT needs this flag to distinguish exported symbols from non-exported ones.</div><div><br></div><div>In the process of trying to write a test case for that, a couple of questions came up:</div><div><br></div><div>(1) Previously COFF wasn't setting either SF_Exported or SF_Hidden. What is the linker using to build the export table for DSOs? Is it just checking the COFF flags directly?</div></div></blockquote><div><br></div></span><div>The linker considers three sources:</div><div>- EXPORTS directives in a .def file given to the linker</div><div>- The linker's /EXPORT option</div><div>- Object files carry a special section, .drectve, which contains additional flags that the linker takes under consideration. __declspec(dllexport) is typically implemented by adding a /EXPORT entry for a particular symbol in there (e.g. /EXPORT:_foo).</div><span><div> <br></div><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><br></div><div>(2) Is there any situation where 'SF_Exported' isn't just the inverse of 'SF_Hidden'? Can we get rid of one or the other of those flags?</div></div></blockquote><div><br></div></span><div>I don't believe so. Normal static functions will have local binding but default visibility. Such a function would be neither hidden nor exported.</div><span><div> </div><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><br></div><div>(3) It looks like the symbol table dump format in both llvm-objdump and llvm-nm is different for different object file formats. Should we be listing the state of SF_Exported/SF_Hidden (or their format-specific counterparts) in llvm-objdump or llvm-nm? If not, where's the most reasonable place to dump the state of this flag? If nowhere else suits I can add a new symbol-table dumping option to llvm-rtydld to expose this.</div></div></blockquote><div><br></div></span><div>I believe readobj already dumps this sort of information out, albeit in object file specific ways.</div><div> </div><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><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div></div></div>