similar to: RFC: Move parts of llvm-symbolizer tool implementation to LLVMSymbolize library

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

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

I work on a linux program with restricted RSS limits (a couple hundred MB), and one of the things this program does is symbolication. Ideally, we'd like to use llvm-symbolizer for this symbolication (because we get things like function inlining that we can't get from cheaper symbolizers), but for large binaries, the memory usage gets pretty huge. Based on some memory profiling, it looks

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 >

# 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

On Tue, Nov 3, 2015 at 5:06 PM, Alexey Samsonov <vonosmas at gmail.com> wrote: > SGTM. This will bring us closer to the point when we can write tests, > where we strip out the .dwo files from executables, package them together > with llvm-dwp, and then verify that we still get all we need from > llvm-symbolizer. > Not quite following here - dwo sections are already stripped

Hi, [ I Cc'd lld people and debug info people. Apologies if I omitted some stakeholder. ] As stated in the subject, I’d like to start working on an in-tree reimplementation of Darwin’s dsymutil utility. This is an initial step on the path to having lld handle the debug information itself. For those who are not familiar with the debug flow on MacOS, dsymutil is a DWARF linker. Darwin’s

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

So, after many shenanigans, we finally have -gmlt-like inline summary debug info in .debug_info when using -gsplit-dwarf (see r221306). Hooray \o/ Testing this with asan, it seems to be working: Given a simple example of inlining failure: $ cat asan.cpp __attribute__((always_inline)) inline void func(int* i) { *i = 3; } int main() { func(nullptr); } The failures before this change: #0

If running ASan on the host architecture, we can symbolize output with: export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` ./myInstrumentedProgram but on Android symbolizing is more complex. The bash script below is a "hello world" for symbolizing ASan output on Android. Is there a simpler way to do this? # Execute the test and save its output adb push

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

Hi all, TL;DR 1) We should change the way we parse common runtime flags in sanitizers. 2) We should make ASan aware of the tools it can be combined with (LSan and UBSan). 3) We may have to restrict the tools UBSan can be combined with (currently to ASan) (see [1]) Currently we have two kinds of sanitizer runtime flags: tool-specific flags and "common flags", defined in sanitizer_common

Thanks for letting me know that this is in the works. This is something that would make running ASan (and all other sanitizers I assume) quite a bit more appealing on Android. If there's anything I can do to help, please let me know. If you'd like to discuss in person, I'll be at the Developers' Meeting next week. -Greg On Thu, Oct 31, 2013 at 1:58 PM, Alexey Samsonov

On Mon, Dec 8, 2014 at 2:00 AM, Alexander Potapenko <glider at google.com> wrote: > Hope you're assuming there's always a single copy of common_flags in > the process. > This isn't the case for e.g. ASan+UBSan on Mac, but that's a broken setup. > > What if we let the tools protect specific flags (by adding a bool to > each flag) once they set their values

Hello Everyone , We have the legacy code ,that uses the .stabs directive quiet often in the source code like .stabs "symbol_name", 100, 0, 0, 0 + .label_one f; .label_one stmt and ,the above code is wrapped with the inline asm in the c source file . we are using clang 3.8(with lto) and as you know that builtin assembler / MC streamer don't have support fir .stabs

Yes, zlib build for LTO will work, but user will have to build this lib from zlib source code anyway. On Fri, Sep 23, 2016 at 4:01 PM Mehdi Amini <mehdi.amini at apple.com> wrote: > > On Sep 23, 2016, at 1:44 PM, Vitaly Buka via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Is it possible to add zlib source code into llvm repo? Any advice on how

On Wed, Oct 30, 2013 at 2:08 PM, Greg Fitzgerald <garious at gmail.com> wrote: > If running ASan on the host architecture, we can symbolize output with: > > export LLVM_SYMBOLIZER_PATH=`which llvm-symbolizer` > ./myInstrumentedProgram > > but on Android symbolizing is more complex. The bash script below is > a "hello world" for symbolizing ASan output

Hi Jake. Thanks for the info. Where can I keep up to date on the symbolizer status? Our symbolizer is provided by the Myriad vendor and integrated into its host test environment. It doesn't do much: just look for PC string patterns and symbolize them using addr2line. Thanks, Walter On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote: > Hey, > I