<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 10, 2017 at 11:51 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2017-06-10 11:39 GMT-07:00 Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</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>On Sat, Jun 10, 2017 at 11:00 AM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>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>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></span><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></div></div></blockquote><div><br></div></span><div>The ODR table (including its string table) is created by the compiler and is unaffected by dropped functions. </div></div></div></div></blockquote><div><br></div></span><div>Does it mean that when we merge two bitcodes files, the two ODR tables for these files are merged as well? In which case if both files contain function `foo` we will have two hashes for `foo` in the table of the resulting file?</div></div></div></div></blockquote><div><br></div><div>The resulting file would have two ODR tables, both of which would have a entry for the function 'foo'.<br></div><div><br></div><div>Peter </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="HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div></font></span><div><div class="h5"><div><br></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"><div>Functions can be dropped by the optimizer in the non-LTO case as well, of course, and we'd still want to be able to diagnose ODR mismatches in those functions.</div><div><br></div><div>In any case, I think we'd want the ODR checker to always be driven by the linker, not the IRMover. This is so that we can properly diagnose ODR mismatches between bitcode files and regular object files, and avoid needing to deal with duplicate diagnostics (say if we import the same pair of ODR-mismatching modules into two different ThinLTO backends), and avoid bad interactions with the ThinLTO cache (we don't want to miss diagnostics because of a ThinLTO cache hit). The way I imagine that this would work is that we'd add something to lto::InputFile that gives the client access to the ODR table.</div><div><br></div><div>That said, we may want to reconsider the blob representation if we want to try and share strings between the object file's string table and the ODR table, as discussed elsewhere.</div><div><br></div><div>Peter</div><div><div class="m_4644486920874804429h5"><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_extra"><div class="gmail_quote"><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><div class="m_4644486920874804429m_-6578256885329532040h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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><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_4644486920874804429m_-6578256885329532040m_7266388037625381195m_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_4644486920874804429m_-6578256885329532040m_7266388037625381195m_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_4644486920874804429m_-6578256885329532040m_7266388037625381195m_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="m_4644486920874804429m_-6578256885329532040m_7266388037625381195HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_4644486920874804429m_-6578256885329532040m_7266388037625381195m_9151753516238781234m_-4487879908425857757gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
<br></div></div>______________________________<wbr>_________________<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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div></div></div><span class="m_4644486920874804429HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_4644486920874804429m_-6578256885329532040gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</div></div>