<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-06-07 16:32 GMT-07:00 Peter Collingbourne via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Wed, Jun 7, 2017 at 8:18 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Does this need LLVM support - or is there some generic representation that could be used instead? (I guess LLVM would want to be aware of it when merging modules though, so maybe it's worth having a first-class representation - though LLVM module linking could special case a section the same way the linker could/would - not sure what's the better choice there)<br></div></blockquote><div><br></div></span><div>The only thing that LLVM needs to do is to have some way to store a blob that will be emitted to the object file. In my prototype I just create a GlobalVariable with private linkage, I think in the final version I will use an MDString referenced by a named MD node. I don't think we would want a higher level representation -- I'd imagine that the blob would be entirely a property of the source code, so I can't see anything that an IR-level pass would want to do with it. It's similar to some parts of debug info in that there's no real benefit to representing it as anything other than a blob.</div></div></div></div></blockquote><div><br></div><div>If you IR Link two modules, you'd want to check that the hash matches and diagnose immediately before dropping link once_odr functions, right?</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I was thinking (hand-wavingly vague since I don't know that much about object files, etc) one of those auto-appending sections and an array of constchar*+hash attributed to that section. (then even without an odr-checking aware linker (which would compare and discard these sections) the data could be merged & a post-processing pass on the binary could still point out ODR violations without anything in the toolchain (except clang) needing to support this extra info)<br></div></blockquote><div><br></div></span><div>Linkers merge section contents by section name, so you wouldn't need anything other than for the object files to agree on a section name. The odrtab header in my prototype has a size field, so we could use that to split an .odrtab section into multiple odrtabs.</div><div><br></div><div>Peter</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><div class="m_9151753516238781234m_-4487879908425857757h5"><div dir="ltr">On Tue, Jun 6, 2017 at 10:41 PM Peter Collingbourne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_9151753516238781234m_-4487879908425857757h5"><div dir="ltr">Hi all,<div><br></div><div>I'd like to propose an ODR checker feature for Clang and LLD. The feature would be similar to gold's --detect-odr-violations feature, but better: we can rely on integration with clang to avoid relying on debug info and to perform more precise matching.</div><div><br></div><div>The basic idea is that we use clang's ability to create ODR hashes for declarations. ODR hashes are computed using all information about a declaration that is ODR-relevant. If the flag -fdetect-odr-violations is passed, Clang will store the ODR hashes in a so-called ODR table in each object file. Each ODR table will contain a mapping from mangled declaration names to ODR hashes. At link time, the linker will read the ODR table and report any mismatches.<br></div><div><div><br></div><div><div><div>To make this work:</div><div>- LLVM will be extended with the ability to represent ODR tables in the IR and emit them to object files</div><div>- Clang will be extended with the ability to emit ODR tables using ODR hashes</div></div><div>- LLD will be extended to read ODR tables from object files</div></div><div><br></div><div><div>I have implemented a prototype of this feature. It is available here: <a href="https://github.com/pcc/llvm-project/tree/odr-checker" target="_blank">https://github.com/pcc/l<wbr>lvm-project/tree/odr-checker</a> a<wbr>nd some results from applying it to chromium are here: <a href="http://crbug.com/726071" target="_blank">crbug.com/726071</a></div><div>As you can see it did indeed find a number of real ODR violations in Chromium, including some that wouldn't be detectable using debug info.</div><div><br></div><div>If you're interested in what the format of the ODR table would look like, that prototype shows pretty much what I had in mind, but I expect many other aspects of the implementation to change as it is upstreamed.</div><div><br></div></div><div>Thanks,</div>-- <br><div class="m_9151753516238781234m_-4487879908425857757m_6926588128544804345m_-4303253202118238788gmail-m_-7030506920794196484gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div></div></div><span>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</span></blockquote></div></div>
</blockquote></span></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_9151753516238781234m_-4487879908425857757gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>