<br><br><div class="gmail_quote">On Thu, May 31, 2012 at 5:38 PM, Dmitry Vyukov <span dir="ltr"><<a href="mailto:dvyukov@google.com" target="_blank">dvyukov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div class="im">On Thu, May 31, 2012 at 5:32 PM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What's the goal of this stub? Why is it needed, and how will it fit into the bigger picture?</blockquote>

<div><br></div></div><div>Dynamic tools (AddressSanitizer and ThreadSanitizer) need to symbolize code locations to produce fine stack traces.</div></blockquote></div><br></div><div>I'm not sure I was sufficiently precise here: the key word in my query was "stub".</div>



<div><br></div><div>I understand the need for symbolization. I was trying to get the review thread (and hopefully the comments in the source files) to reflect why the particular stub interface proposed in the location it was proposed was needed, and how it might interact with the symbolization library that is to grow inside of LLVM's core libraries.</div>



</blockquote></div><div><br></div></div></div>OIC. Location is /compiler-rt/lib/sanitizer_common as symbolizer would be used by runtime libraries of both sanitizer tools, and would likely use much of low-level code they share. It would also call LLVM debug info library. In fact, this might be a concern, as that library should be lightweight enough to be called from ASan/TSan runtime (and, afaiu from dvukov@ we might have to fix it a bit).<span><font color="#888888"><div>


<div><br></div></div></font></span></blockquote><div><br></div></div><div>We don't use libstdc++, STL, libc, global ctors, big stack frames, etc.</div></div></blockquote><div><br></div><div>These are serious constraints. Did you look if we can actually use anything from LLVMSupport, for example?</div>
<div><br></div><div>-- </div></div><div>Alexey Samsonov, MSK</div>