similar to: llvm-symbolizer memory usage

# Summary Currently the Sanitizer family of runtime bug finding tools (e.g. Address Sanitizer) provide useful reports of problems upon detection. This RFC proposes adding tools to 1. Parse Sanitizer reports into structured data to make interfacing with other tools simpler. 2. Take the Sanitizer reports and “Symbolicate” them. That is, add missing symbol information (function name, source file,

Hi, On Tue, 6 Oct 2020 at 18:31, David Blaikie <dblaikie at gmail.com> wrote: > > My 2c would be to push back a bit more on the "let's not have a machine readable format, but instead parse the human readable format" - it seems like that's going to make the human readable format/parsing fairly brittle/hard to change (I mean, having the parser in tree will help, for

Hi, We have a lot of non-trivial logic accumulated in the implementation of llvm-symbolizer tool (tools/llvm-symbolizer/LLVMSymbolize.{h,cpp}), for instance: * dynamic dispatch between DWARF and PDB debug info; * building address->symbol_name mapping from object file (with special cases for PowerPC function descriptor section, and COFF export tables); * finding debug info stored in separate

To create unit tests is a pretty good reason IMO :) That said, I'd be a fan of trying to encapsulate all of this behind an interface. I like that most of the tools are exceptionally light weight and it makes it much more obvious what's "wrapper" versus "functionality" in something like llvm-symbolize. That said, I'll be interested to see the library design :)

In an effort to fix inlined information for backtraces under DWARF Fission in the absence of the split DWARF (.dwo) files, I'm planning on adding -gmlt-like data to the .o file, alongside the skeleton CU. Since that will involve teaching the LLVM about -gmlt (moreso than it already has - the debug info LLVM metadata already describes -gmlt for the purposes of omitting pubnames in that case) I

On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <vonosmas at gmail.com> wrote: > We have out-of-tree implementation of llvm-symbolizer-as-a-library, and I > still hope to upstream it one day (unfortunately, its build process is > really complicated). > > Mike can probably comment on his plans for using symbolization in > coverage-related tools. > > On Wed, Oct 21,

On Thu, Aug 28, 2014 at 11:51 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > This sounds great. Teaching backend about the -gmlt might help us in > another way: we might enforce full debug info generation in the frontend > for -fsanitize= flags, then rely on some parts of this debug info in > instrumentation passes and prune it before the actual object file >

On Wed, Oct 21, 2015 at 1:21 PM Alexey Samsonov <vonosmas at gmail.com> wrote: > On Wed, Oct 21, 2015 at 12:59 PM, Eric Christopher <echristo at gmail.com> > wrote: > >> >> >> On Wed, Oct 21, 2015 at 12:17 PM Alexey Samsonov <vonosmas at gmail.com> >> wrote: >> >>> We have out-of-tree implementation of llvm-symbolizer-as-a-library,

Even if I turn to -O0 [in other words, no optimisation passes at all], it takes the same amount of time. The time is spent in 12.94% lacsap lacsap [.] llvm::SDNode::use_iterator::operator== 7.68% lacsap lacsap [.] llvm::SDNode::use_iterator::operator* 7.53% lacsap lacsap [.] llvm::SelectionDAG::ReplaceAllUsesOfValueWith 7.28% lacsap

I've definitely "run into this problem", and I would very much love to remove my kludges [that are incomplete, because I keep finding places where I need to modify the code-gen to "fix" the same problem - this is probably par for the course from a complete amateur compiler writer and someone that has only spent the last 14 months working (as a hobby) with LLVM]. So whilst

Hey, LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to search in the codebase to see if there's a possibility to add/remove sections after parsing a binary and re-write the binary to another location. Basically, like what llvm-objcopy does. Can you point me to the right classes to look into, if this is something that LLVM has? Many thanks Joseph

Hi everyone, I’m currently playing with the clang driver and I encounter a strange bug. It occurs when I used the getSize function from the SymbolRef class. On iOS, the number returned is not always correct (some function have the right size). Sadly, This is my code (at the end of the main function into driver.cpp) : #### ErrorOr<OwningBinary<Binary>> BinaryOrErr =

    Hello all,     I develop a project based on Clang where I need to read all symbols from a library. For symbols libraries (.a/.lib) I use the following code:     auto &FM = C->getFileManager();     ...     auto Buffer = FM.getBufferForFile(FileEntry);     ...     auto Object = llvm::object::ObjectFile::createObjectFile(Buffer);     This code crashes at the last line if the file in

On 2020-08-13, David Blaikie via llvm-dev wrote: >Sounds like the llvm-objcopy source code (llvm/tools/llvm-objcopy) is >probably a good place to start. > >On Thu, Aug 13, 2020 at 8:11 AM Joseph via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> >> Hey, >> >> LLVM has logic to parse ELF and PE binaries using `llvm::object::createBinary`. I tried to

On Wed, May 7, 2014 at 11:33 AM, Eric Christopher <echristo at gmail.com>wrote: > Have you checked out llvm-symbolize? It's what the asan folk > (including Alexey) have created for backtrace symbolication. > Yeah, we potentially can add some kind of option: "llvm-symbolizer -print-short-function-names", I don't yet see why this would be valuable. What's wrong

On Wed, May 7, 2014 at 11:38 AM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The use case for this is in Julia backtraces. We don't have a consistent > way to mangle the function names for linkage (we might at some point in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access

no expression parser or knowledge of any specific programming language. Basically I just mean that the parsing of the native DWARF format itself is in scope, but anything beyond that is out of scope. For symbolication we have things like llvm-symbolizer that already just work and are built on top of LLVM's dwarf parsing code. Similarly, LLDB's type system could be built on top of it as

Yes definitely, testing a small piece of code like the GlobPattern::create() example, it would mostly indicate missing unit tests or insufficient test data. In contrast to unit tests, however, it can also verify correct handling of errors passed between function call hierarchies in more complex scenarios. For this I should point to the other example in the code, where it's applied to

I am trying to run NFS-Ganesha with ASAN in our setup. I am having difficulties to make llvm symbolizer print symbol names from the .debug binaries/libraries, once ASAN shows any error; bash-4.2# /opt/rh/llvm-toolset-7/root/usr/bin/llvm-symbolizer --version LLVM (http://llvm.org/): LLVM version 5.0.1 Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: nocona I am getting

Hi Stefan, David, This is very interesting stuff - it adds a dimension of error security that Error/Expected can't provide on their own. I think it would be interesting to try to build a tool around this. Did you identify many cases where "real work" (in your example, the nullptr dereference" was being done in an error branch? My suspicion is that that should be rare, but that