<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 21, 2015 at 1:21 PM Alexey Samsonov <<a href="mailto:vonosmas@gmail.com">vonosmas@gmail.com</a>> wrote:<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">On Wed, Oct 21, 2015 at 12:59 PM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@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><br><div class="gmail_quote"><span><div dir="ltr">On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>> wrote:<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">We have out-of-tree implementation of llvm-symbolizer-as-a-library, and I still hope to upstream it one day (unfortunately, its build process is really complicated).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mike can probably comment on his plans for using symbolization in coverage-related tools.</div><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 21, 2015 at 11:34 AM, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@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">To create unit tests is a pretty good reason IMO :)<div><br></div><div>That said, I'd be a fan of trying to encapsulate all of this behind an interface. I like that most of the tools are exceptionally light weight and it makes it much more obvious what's "wrapper" versus "functionality" in something like llvm-symbolize. That said, I'll be interested to see the library design :)</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Do you suggest to design it upfront, or you're fine with moving the existing code first, and gradually updating the interface afterwards?</div></div></div></div></blockquote><div><br></div></span><div>Don't know, what's the interface look like now? :) Were you just going to copy the LLVMSymbolize.[cpp,h] into the directory?</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>For a start, yes.</div></div></div></div></blockquote><div><br></div><div>OK.</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> </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> That should be fine I guess. I'd like to see the general ownership of objects separated out fairly explicitly from the rest of the code.</div></div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'm not sure what you mean by this.</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div></div></div></div></blockquote><div><br></div><div>Is LLVMSymbolizer owning all of the files the right choice, or what was convenient at the time?</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"><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"><span><font color="#888888"><div><br></div><div>-eric</div></font></span><div><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> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>-eric</div></div><br><div class="gmail_quote"><div><div><div dir="ltr">On Wed, Oct 21, 2015 at 7:35 AM Rafael Espíndola <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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>I would say it is worth it if someone is actually planning on using<br>
the library in something else.<br>
<br>
Moving the code "just in case" or to create unit tests is not a good<br>
reason IMHO.<br>
<br>
On 20 October 2015 at 16:54, Alexey Samsonov <<a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> We have a lot of non-trivial logic accumulated in the<br>
> implementation of llvm-symbolizer tool<br>
> (tools/llvm-symbolizer/LLVMSymbolize.{h,cpp}), for instance:<br>
><br>
> * dynamic dispatch between DWARF and PDB debug info;<br>
> * building address->symbol_name mapping from object file (with special cases<br>
> for PowerPC function descriptor section, and COFF export tables);<br>
> * finding debug info stored in separate files (.dSYM files on Darwin, ELF<br>
> .gnu_debuglink section, etc.);<br>
> * demangling (with platform-specific implementations for Windows and Unix).<br>
><br>
> I propose to move this code into a separate library LLVMSymbolize (stored<br>
> under lib/DebugInfo/Symbolize), and make llvm-symbolizer a short and simple<br>
> tool using it. This would allow to:<br>
><br>
> * implement in-process symbolized stack trace printers (for the cases when<br>
> it's possible to link in a bunch of LLVM libraries into the executable).<br>
> * easily write more tools that can make use of symbolized code locations,<br>
> such as coverage data visualizers.<br>
> * (at least sometimes) write unit tests instead of testing functionality by<br>
> running "llvm-symbolizer" executable on pre-built executables checked in<br>
> repository.<br>
><br>
> Any comments/objections?<br>
><br>
> --<br>
> Alexey Samsonov<br>
> <a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a><br></div></div>
_______________________________________________<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>
</blockquote></div>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div></blockquote></div></div></div></div>
</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Alexey Samsonov<br><a href="mailto:vonosmas@gmail.com" target="_blank">vonosmas@gmail.com</a></div></div>
</div></div></blockquote></div></div>