search for: demangler

...bolname) SymbolErrorKind := MultipleDefinition Undefined GroupError Note (for tracing) ... > Seems like a demangling utility might be something to add at the LLVM level. Either directly to raw_ostream or a wrapper like format(). I have browsed discussions in llvm related to this to move the demangler function which is housed in libcxx, and I dont think there is a plan to move that. I think the format() specifier would be one thing that would be useful, but I am not sure on how different linking contexts in lld, could route calls with a central format specifier. Can you share more info on...

Hi Nick, Bigcheese, When lld is used to link C++ code, it would be required to demangle symbol names by default/user driven option. The Gnu linker has the following options :- --demangle=[style] --no-demangle I found that clang/llvm-symbolizer use __cxx_demangle function. I would think that lld also need to call the same function, and I think the way we want to demangle is to have the

On 6/21/17 5:42 PM, Rui Ueyama wrote: > I'm very interested in your work because I've just started writing a > demangler for the Microsoft mangling scheme. What I found in the > current Itanium demangler is the same as you -- it looks like it > allocates too much memory during parsing and concatenates std::strings > too often. I could see there's a (probably big) room to improve. > Demangler's...

...ems like it would always be: > str = sym; > if (ctx.canDemangle()) > str = ctx.demangle(sym); > > My suggestion is to move the canDemangle functionality into demangle, so clients just always use: > str = ctx.demangle(sym); > and it returns the input string if a demangler is not available or is disabled. > Yes. This would be much preferrred. >> One demangle method wouldnt work as the ItaniumABI uses one method to demangle, ARMCXXABI uses a different method, and MSVC uses a different one. I am not sure about Mach-O here ? > Given that, how can we make an...

This is Greg's area, he'll be able to answer in detail how the name chopper gets used. IIRC it chops demangled names, so it is indirectly a client of the demangler, but it doesn't use the demangler to do this directly. Name lookup is done by finding all the base name matches, then comparing the context. We don't do a very good job of doing fuzzy full name matches - for instance when trying to break on one overload you have to get the arguments exact...

Hi all, We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that we use with the demangler that we currently use. The demangler that is currently in the LLVM tree appears to be a copy of the l...

...AST would enable us to do that. I was thinking about this use case a little, actually. I think it makes more sense to provide a function, say getItaniumDemangledBasename(), which could just parse and query the AST for the base name (the AST already has an way of doing this). This would allow the demangler to bail out if it knows that the rest of the input string isn’t relevant, i.e., we could bail out after parsing the ‘foo’ in _Z3fooiiiiiii. That, and not having to print out the AST should make parsing the base name significantly faster on top of this. Do you have any other use case for the AST ou...

...M, Vedant Kumar via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> > wrote: > > > > well, top-of-branch lldb uses this code, that's how I found it. Do you > mean libc++'s demangler? > > Thanks for explaining, this is the first time I'm looking at the demangler > situation. It looks like libcxxabi has an arena-based demangler, and that > the one in llvm is different. > > I'm confused by this because the comment in llvm says that libcxxabi is > supp...

Hi, AFAIK, the tools "symbolizer, objdump and nm" need a demangler. I see there is libcxxabi which provides the demangle library. But there is no support to build libcxxabi on windows with MSVC. This left a huge void and my symbolizer cannot work on Windows if built with MSVC. Instead of mucking around OS dependencies, why shouldn't we have a demangle l...

> On Dec 15, 2016, at 6:18 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > > We’re hoping to replace the demangler in some of our tools to use the LLVM demangler. We’d like to enhance it with missing functionality (legal names that it cannot demangle) and provide a set of tests that we use with the demangler that we currently use. > > > The demangler that is currently in the LLVM tree appears to be...

On Thu, May 5, 2016 at 10:58 AM, Duncan P. N. Exon Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Kate > > We already have two demangler implementations (LLDB and libcxxabi). I'd > rather not have three. Have you looked at the LLDB one? I think Kate has > some patches she hasn't had a chance to commit yet that add functionality. > I heard something like 10x faster, and way less stack usage (although not > quit...

well, top-of-branch lldb uses this code, that's how I found it. Do you mean libc++'s demangler? FYI when I said 14+% (and now it's 17%), I mean the overall performance of starting lldb, not just the demangler itself. It's probably several times faster now with this change (https://reviews.llvm.org/D32500) On Tue, Apr 25, 2017 at 12:19 PM, Vedant Kumar <vsk at apple.com> wro...

...> llvm-dev at lists.llvm.org> wrote: > >> >> > On Apr 25, 2017, at 12:24 PM, Scott Smith <scott.smith at purestorage.com> >> wrote: >> > >> > well, top-of-branch lldb uses this code, that's how I found it. Do you >> mean libc++'s demangler? >> >> Thanks for explaining, this is the first time I'm looking at the >> demangler situation. It looks like libcxxabi has an arena-based demangler, >> and that the one in llvm is different. >> >> I'm confused by this because the comment in llvm says tha...

On Tue, Jun 20, 2017 at 10:17 AM, Robinson, Paul <paul.robinson at sony.com> wrote: > Just to be clear - once LLVM has its own demangler, it should probably use > it on all platforms, so there'd be no worry about different behavior > between LLVM on Windows and LLVM elsewhere. > > But that said, it's probably still important/worthwhile to make sure it's > consistent with the platform demangler. > > &...

...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. libc++abi provides a full C++ demangler, along with an extended API that...

(though, usual caveat: you /usually/ shouldn't be doing that - instead relying only on whatever semantics the IR actually carries, rather than implying extra semantics based on the demangled name) On Wed, Jun 24, 2020 at 12:48 PM Johannes Doerfert via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I have not tried it but maybe > > `std::string llvm::demangle(const

...te: > >> On 2016-May-05, at 11:14, David Majnemer <david.majnemer at gmail.com> wrote: >> >> On Thu, May 5, 2016 at 10:58 AM, Duncan P. N. Exon Smith via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> +Kate >>> >>> We already have two demangler implementations (LLDB and libcxxabi). I'd rather not have three. Have you looked at the LLDB one? I think Kate has some patches she hasn't had a chance to commit yet that add functionality. I heard something like 10x faster, and way less stack usage (although not quite fully functional...

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

.... 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. - Michael Spencer

On 4/4/2014 3:46 AM, David Chisnall wrote: > On 3 Apr 2014, at 20:49, Shankar Easwaran <shankare at codeaurora.org> wrote: > >> b) I am not planning to write a demangler. I was planning on using abi::__cxx_demangle if there was one available and the first character in the symbol was a _. >> If MSVC was defined, we would use the Undecorate API. > The demangler that Howard wrote for libc++abi was intended to be general and reusable. It was rewritten eve...