<html><head></head><body bgcolor="#FFFFFF"><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">On Jul 5, 2012, at 1:08 AM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</span><br></div><div><br></div><div></div><blockquote type="cite"><div>In the same way that the core LLVM libraries have support routines for DWARF, I think that both mangling and demangling should be provided as well.</div></blockquote><div><br></div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">How would LLVM provide support for mangling? And what tools actually need it? I also wonder if we need more from a demangler than just a string. I know linker diagnostics would benefit from a deeper understanding of the name without having to parse C++ decls.</span><div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469);"><br></span><blockquote type="cite"><div> I suspect that the 'Support' library is the best we have, although eventually we need to split this library up a bit. That's not really your problem though.<div>
<br></div></div></blockquote><div><br></div><div>I don't see anywhere to split Support. We already merged System and Support because of the circular deps. However I agree that demangling can be in another library.</div><br><blockquote type="cite"><div><div>The bigger problem is that we don't have any good way of sharing code between runtime libraries (such as libcxxabi, sanitizer runtimes, etc) and LLVM.</div><div><br></div><div>One somewhat interesting question, would the APIs exposed by libcxxabi be sufficient for the sanitizer runtimes?</div>
<div><br></div><div>AFAICT, the only other way forward is to:</div><div><br></div><div>1) Move/re-implement the demangling (and hopefully the mangling as well) into llvm/Support, following proper style and writing proper unittests as we go.</div>
<div>2) Write my object-file-scrubber so that we can statically link llvm/Support into a runtime without collision issues.</div><div>3) Potentially split up llvm/Support (and other libraries) enough to have depending upon it not burden or bloat the runtime libraries unnecessarily.</div>
<div><br></div><div><br></div><div>All of these options seem... moderately painful. My inclination is to start paving the way for better code sharing in runtime libraries sooner rather than later. Other thoughts? Chris?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 4, 2012 at 9:53 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"><br><br><div class="gmail_quote"><div class="im">On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@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><div>On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>> wrote:<br>
> Hello!<br>
><br>
> We want to implement in-process symbolizer for {Address,Thread}Sanitizer<br>
> testing tools that would be based on LLVM libraries.<br>
> I've noticed that llvm-nm (as well as other tools) doesn't demangle C++<br>
> names. Is it true, that LLVM doesn't have the code that is capable<br>
> of that, and if yes, are there any plans to add it?<br>
> Depending on something like libiberty.a doesn't seem like a good or portable<br>
> solution.<br>
><br>
> --<br>
> Alexey Samsonov, MSK<br>
><br>
<br>
</div></div>Yes, LLVM currently has no C++ demangler, and it needs one. Although I<br>
have no idea where it should live. It would be nice if it could live<br>
in clang next to the mangler, but clang doesn't even need a demangler.<br>
llvm tools, lld, and compiler-rt do.</blockquote><div><br></div></div><div>llvm/Support?</div><div><br></div><div>It's not that clear how libcxxabi could be used in llvm tools, as IIUC this library is built independently.</div>
<div>The demangler implementation there is 10 KLOC which are rather far from LLVM style.</div></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div><br>
</font></span><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">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></div></body></html>