search for: cxa_demangler

...targets running on OSS-Fuzz, a continuous > > automated fuzzing service: > > https://github.com/google/oss-fuzz > > https://www.usenix.org/sites/default/files/conference/protected-files/ > usenixsecurity17_slides_serebryany.pdf > > > > It has reported a few bugs in cxa_demangler, clang, and dwarfdump > already, > > and we expect to add more fuzz targets to it soon (llvm-isel-fuzzer, > > clang-format-fuzzer, ...) > > > > A question to everyone: how do we report these bugs properly? > > OSS-Fuzz files bugs automatically into a separate bug tr...

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

...; automated fuzzing service: > >> > https://github.com/google/oss-fuzz > >> > https://www.usenix.org/sites/default/files/conference/ > protected-files/ > >> usenixsecurity17_slides_serebryany.pdf > >> > > >> > It has reported a few bugs in cxa_demangler, clang, and dwarfdump > >> already, > >> > and we expect to add more fuzz targets to it soon (llvm-isel-fuzzer, > >> > clang-format-fuzzer, ...) > >> > > >> > A question to everyone: how do we report these bugs properly? > >> > OS...

Hi, We have several llvm fuzz targets running on OSS-Fuzz, a continuous automated fuzzing service: https://github.com/google/oss-fuzz https://www.usenix.org/sites/default/files/conference/protected-files/usenixsecurity17_slides_serebryany.pdf It has reported a few bugs in cxa_demangler, clang, and dwarfdump already, and we expect to add more fuzz targets to it soon (llvm-isel-fuzzer, clang-format-fuzzer, ...) A question to everyone: how do we report these bugs properly? OSS-Fuzz files bugs automatically into a separate bug tracker, it can not file bugs to bugzilla. By default, t...

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 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 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 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

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)

...building fuzz > target with regular flags (no coverage). > 2. There should also be a bot that actually runs continuous fuzzing. > Our buildbots are not suitable for this, so I was planing to add the llvm > fuzzers to OSS-Fuzz (https://github.com/google/oss-fuzz) > We already run the cxa_demangler fuzzer there with quite a bit of success. > clang-fuzzer is now running on oss-fuzz, and here are two trophies so far: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=3134 ASSERT: ParmVarDeclBits.ScopeDepthOrObjCQuals == scopeDepth && "truncation!" (haven't seen be...

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

Hi, As a part of a recent move of libFuzzer from LLVM to compiler-rt I am looking into updating the build code for the libraries which use libFuzzer. I have tried to compile llvm-mc-assemble-fuzzer, and llvm-mc-disassemble-fuzzer, and I couldn’t build either of those. For the first one, the reason is that it refers to a nonexistent enum, and for the second one I believe the reason is that it

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

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

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

We are trying out lld ELF on windows. It works great, but a big difference from running it on linux is that it cannot demangle c++ names since there is no itanium demangler available on windows. We have an implementation in libcxxabi/src/cxa_demangle.cpp. I see that there was some discussion about having a version of that in lib/Support, but I don't think a patch was ever posted. So, some

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

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>

Hello all, The itanium demangler in libcxxabi (and also, llvm/lib/Demangle) is really slow. This is largely because the textual representation of the symbol that is being demangled is held in a std::string, and manipulations done during parsing are done on that string. The demangler is always concatenating strings and inserting into the middle of strings, which is terrible. The fact that the