On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>wrote:> On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> > wrote: > > Hello! > > > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > > testing tools that would be based on LLVM libraries. > > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ > > names. Is it true, that LLVM doesn't have the code that is capable > > of that, and if yes, are there any plans to add it? > > Depending on something like libiberty.a doesn't seem like a good or > portable > > solution. > > > > -- > > Alexey Samsonov, MSK > > > > Yes, LLVM currently has no C++ demangler, and it needs one. Although I > have no idea where it should live. It would be nice if it could live > in clang next to the mangler, but clang doesn't even need a demangler. > llvm tools, lld, and compiler-rt do.llvm/Support? It's not that clear how libcxxabi could be used in llvm tools, as IIUC this library is built independently. The demangler implementation there is 10 KLOC which are rather far from LLVM style. -- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120705/63a316dd/attachment.html>
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. 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. 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. One somewhat interesting question, would the APIs exposed by libcxxabi be sufficient for the sanitizer runtimes? AFAICT, the only other way forward is to: 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. 2) Write my object-file-scrubber so that we can statically link llvm/Support into a runtime without collision issues. 3) Potentially split up llvm/Support (and other libraries) enough to have depending upon it not burden or bloat the runtime libraries unnecessarily. 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? On Wed, Jul 4, 2012 at 9:53 PM, Alexey Samsonov <samsonov at google.com> wrote:> > > On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > >> On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> >> wrote: >> > Hello! >> > >> > We want to implement in-process symbolizer for {Address,Thread}Sanitizer >> > testing tools that would be based on LLVM libraries. >> > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ >> > names. Is it true, that LLVM doesn't have the code that is capable >> > of that, and if yes, are there any plans to add it? >> > Depending on something like libiberty.a doesn't seem like a good or >> portable >> > solution. >> > >> > -- >> > Alexey Samsonov, MSK >> > >> >> Yes, LLVM currently has no C++ demangler, and it needs one. Although I >> have no idea where it should live. It would be nice if it could live >> in clang next to the mangler, but clang doesn't even need a demangler. >> llvm tools, lld, and compiler-rt do. > > > llvm/Support? > > It's not that clear how libcxxabi could be used in llvm tools, as IIUC > this library is built independently. > The demangler implementation there is 10 KLOC which are rather far from > LLVM style. > > -- > Alexey Samsonov, MSK > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120704/60f2a8ef/attachment.html>
On Thu, Jul 5, 2012 at 9:08 AM, Chandler Carruth <chandlerc at google.com>wrote:> 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. 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. > > 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. >Yes, surely I want this to happen and would be happy to help if you (or someone else) give some advice or guidance.> One somewhat interesting question, would the APIs exposed by libcxxabi be > sufficient for the sanitizer runtimes? >How can we use libcxxabi anyway? I mean, is it shipped with compiler so that we can make Clang driver tell to link user program with libcxxabi in the same way we tell it to link with sanitizer runtimes if flags -fwhatever-sanitizer is present?> AFAICT, the only other way forward is to: > > 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. > 2) Write my object-file-scrubber so that we can statically link > llvm/Support into a runtime without collision issues. > 3) Potentially split up llvm/Support (and other libraries) enough to have > depending upon it not burden or bloat the runtime libraries unnecessarily. > > > 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? >> > > On Wed, Jul 4, 2012 at 9:53 PM, Alexey Samsonov <samsonov at google.com>wrote: > >> >> >> On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: >> >>> On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> >>> wrote: >>> > Hello! >>> > >>> > We want to implement in-process symbolizer for >>> {Address,Thread}Sanitizer >>> > testing tools that would be based on LLVM libraries. >>> > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ >>> > names. Is it true, that LLVM doesn't have the code that is capable >>> > of that, and if yes, are there any plans to add it? >>> > Depending on something like libiberty.a doesn't seem like a good or >>> portable >>> > solution. >>> > >>> > -- >>> > Alexey Samsonov, MSK >>> > >>> >>> Yes, LLVM currently has no C++ demangler, and it needs one. Although I >>> have no idea where it should live. It would be nice if it could live >>> in clang next to the mangler, but clang doesn't even need a demangler. >>> llvm tools, lld, and compiler-rt do. >> >> >> llvm/Support? >> >> It's not that clear how libcxxabi could be used in llvm tools, as IIUC >> this library is built independently. >> The demangler implementation there is 10 KLOC which are rather far from >> LLVM style. >> >> -- >> Alexey Samsonov, MSK >> >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >> >-- Alexey Samsonov, MSK -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120705/9a79febc/attachment.html>
On Jul 5, 2012, at 1:08 AM, Chandler Carruth <chandlerc at google.com> wrote:> 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.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.> 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. >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.> 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. > > One somewhat interesting question, would the APIs exposed by libcxxabi be sufficient for the sanitizer runtimes? > > AFAICT, the only other way forward is to: > > 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. > 2) Write my object-file-scrubber so that we can statically link llvm/Support into a runtime without collision issues. > 3) Potentially split up llvm/Support (and other libraries) enough to have depending upon it not burden or bloat the runtime libraries unnecessarily. > > > 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? > > > On Wed, Jul 4, 2012 at 9:53 PM, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Wed, Jul 4, 2012 at 8:33 AM, Alexey Samsonov <samsonov at google.com> wrote: > > Hello! > > > > We want to implement in-process symbolizer for {Address,Thread}Sanitizer > > testing tools that would be based on LLVM libraries. > > I've noticed that llvm-nm (as well as other tools) doesn't demangle C++ > > names. Is it true, that LLVM doesn't have the code that is capable > > of that, and if yes, are there any plans to add it? > > Depending on something like libiberty.a doesn't seem like a good or portable > > solution. > > > > -- > > Alexey Samsonov, MSK > > > > Yes, LLVM currently has no C++ demangler, and it needs one. Although I > have no idea where it should live. It would be nice if it could live > in clang next to the mangler, but clang doesn't even need a demangler. > llvm tools, lld, and compiler-rt do. > > llvm/Support? > > It's not that clear how libcxxabi could be used in llvm tools, as IIUC this library is built independently. > The demangler implementation there is 10 KLOC which are rather far from LLVM style. > > -- > Alexey Samsonov, MSK > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120705/37cd6568/attachment.html>