<div dir="ltr"><br><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 9:50 AM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<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">On Mon, Mar 23, 2015 at 8:15 AM, Khilan Gudka <span dir="ltr"><<a href="mailto:Khilan.Gudka@cl.cam.ac.uk" target="_blank">Khilan.Gudka@cl.cam.ac.uk</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">Hi David<div><br></div><div>Thanks for your email.</div><div><br></div><div class="gmail_extra"><div class="gmail_quote"><span><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>What's the benefit/purpose of the MDLLVMModule over just having the MDCompileUnits themselves? I would imagine the user cares about which source file the problem was in (obtained from the MDCompileUnit), not the sequence of BC modules that may've been built into?<br></div></div></div></div></blockquote><div><br></div></span><div>We envisage it to be useful when an analysis tool built using LLVM needs to know which MDCompileUnits were part of a particular library that has been linked in. For instance, we're currently analysing the sandboxing behaviour within the Chromium web browser, which comprises hundreds of internal libraries and many external ones. To be able to perform this analysis we have to link them all together into a single .bc/.ll file. </div><div><br></div><div>Having the module structure allows us to model interactions between different modules (without manually (and sometimes unreliably) having to work out which source file corresponds to which library (e.g. libssl, libpci, libpolicy, librenderer, etc)). It also allows an analysis tool to support turning on/off output warnings for particular libraries (as they can lead to a lot of analysis output).</div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>Fair enough - I've no idea/opinion on whether that's the right abstraction (other people with more domain knowledge of analysis infrastructure might chime in with some thoughts).<br><br>Practically speaking: would directory paths be sufficient? The MDCompileUnits already have information about where the source file was.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></div></blockquote><div><br></div><div>I agree, this seems very weird. You have very good source location information down to directory/file/line/column for individual instructions in the existing metadata scheme, I'm not sure what this is getting you over that?</div><div><br></div><div>-eric</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><br>- David<br> </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><div dir="ltr"><div><br></div><div>I would be very grateful if someone could review this.</div><div><br></div><div>Thanks</div><div><br></div><div><div><div dir="ltr"><div><div>--</div>Khilan Gudka</div><div><div>Research Associate</div><div>Security Group</div><div>Computer Laboratory<br></div><div><div>University of Cambridge</div></div><div><a href="http://www.cl.cam.ac.uk/~kg365/" target="_blank">http://www.cl.cam.ac.uk/~kg365/</a></div></div></div></div></div>
<div dir="ltr"><br></div></div>
<br></span>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div></div></div>
______________________________<u></u>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvmdev</a><br>
</blockquote></div></div>