similar to: How to get c++ function demangled name without parameters.

Hi Fangqing, llvm::itaniumDemangle() doesn't yet provide this functionality, but I'm working on adding it in now for the LLDB folks (http://lists.llvm.org/pipermail/lldb-dev/2018-January/013186.html). I should have a patch up Very Soon! If you would like I can CC you to it. Thanks, Erik On 2018-03-16 2:15 PM, Fangqing Du via llvm-dev wrote: > Hi all, > > We know that

On June 22, 2017 at 5:51:39 AM, Pavel Labath (labath at google.com) wrote: I don't have any concrete feedback, but: - +1 for removing the "FastDemagler" - If you already construct an AST as a part of your demangling process, would it be possible to export that AST for external consumption somehow? Right now in lldb we sometimes need to parse the demangled name (to get the

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

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)

On Sun, 4 Mar 2018 at 20:33, John McCall via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Seems like a reasonable project! Maybe we can get a SoC student to make a > standalone C++ demangler library with a tree API (an unstable one should be > fine), and debuggers can just use that instead of relying on the OS's > cxa_demangle. (I'm really not sure why

On 6/22/17 7:50 AM, Joerg Sonnenberger via llvm-dev wrote: > On Wed, Jun 21, 2017 at 04:42:40PM -0700, Erik Pilkington via llvm-dev wrote: >> I've been working on fixing this by parsing first into an AST structure, and >> then traversing that AST to produce a demangled string. This provides a >> significant performance improvement and also make the demangler somewhat

> On Mar 4, 2018, at 10:20 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote: >> On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> To

On Sun, Mar 4, 2018 at 12:33 AM, John McCall <rjmccall at apple.com> wrote: > On Mar 3, 2018, at 11:30 PM, Daniel Berlin via cfe-dev < > cfe-dev at lists.llvm.org> wrote: > > To explain to others who didn't follow that thread: > > GDB currently does something amazingly stupid (and has since i wrote it) > to find the RTTI type. There were no other good options

On Jul 4, 2012, at 12:43 PM, Michael Spencer 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

Thank you Hal and Stefan! Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 And Stefan, I think 'attributor' is a really nice pass, and can infer more precise and useful attributes, which may give more opportunities for optimization. But we shouldn't depend on 'attributor' to correct wrong function attributes, because we cannot run 'attributor' after

On Tue, Apr 25, 2017 at 1:37 PM, Asiri Rathnayake < asiri.rathnayake at gmail.com> wrote: > > > On Tue, Apr 25, 2017 at 8:36 PM, 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

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

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

Hi all, Let's see an example (from Alexandre Isoard) first: **************************************************************************************** ; RUN: opt -ipsccp -deadargelim -licm -O2 -S < %s @g = internal global i32 0 ; Function Attrs: argmemonly define internal void @foo(i32* nonnull dereferenceable(4) %arg, i32 %val) #0 { entry: store i32 %val, i32* %arg ret void } define

We've been using the runtimes build for a while now and we're very happy with it. However, with an increasing number of targets, it can be fairly slow and I have noticed that we now spend more time in CMake than in Ninja. There are various ways we could improve things like eliminating unnecessary checks. When running checks like check_c_compiler_flag, check_cxx_compiler_flag or

On Tue, Apr 25, 2017 at 8:36 PM, 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

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>

The main goal of these patch series is to implement a new API that allows to retrieve created device-mapper devices for volumes and partitions back after they have been created. As part of this patch: - required libdevmapper version was bumped to 1.02. I think it is safe because it was released more then 10 years ago; - newer version of libdevmapper allowed to simplify code base a little bit; -

> On Sep 22, 2020, at 15:28, Eric Christopher <echristo at gmail.com> wrote: > > From the "not largely affected" camp: > > - the churn doesn't feel that major for HAS_ and ... > - the uniformity feels nice > > and in general feels nice and in pursuit of the longer term goals here. > > -eric > > On Tue, Sep 22, 2020 at 11:58 AM Petr

Was there any resolution about if bringing this into the LLVM Support directory should be done or not? I have a need of being able to use this, not just for demangling, but also to verify correctness of a mangled function, and can only rely on LLVM core. Thanks, Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf