similar to: [LLVMdev] Formats supported by llvm/Object/Archive.h

On Fri, Aug 3, 2012 at 6:45 AM, Alexey Samsonov <samsonov at google.com> wrote: > Hi, llvmdev > > I've tried to use llvm/Object/Archive.h to print the archive symbol table > for standard Unix .a files by slightly extending a code in llvm-nm, > and the code crashed with wild segfault. It looks like the implementation in > lib/Object/Archive.cpp assumes completely

(resurrecting the thread, as much is discussed here already) Formulating Kostya's suggestion: What do you think of compiling LLVM sources into ASan/TSan runtime by just taking the library sources, providing custom compiler (target) flags *and* a flag "-Dllvm=__sanitizer_llvm"? Yeah, it's hacky and applicable to LLVM libs, but OTOH we don't plan to use smth else for now (in

Hi all, compiler-rt is now not only a libgcc replacement for different platforms, there are sanitizer and profile runtimes as well. I plan to move the files as follows during this week: 1. libraries: a) all libgcc replacement stuff moves from "/lib" to "/lib/core" (the name sucks, please suggest alternatives). Same for platform-specific code:

On Wed, Jul 4, 2012 at 11:43 PM, Michael Spencer <bigcheesegs at gmail.com>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

On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com>wrote: > Yes, at some point we definitely should introduce stubs as a last resort > for x86-64 relocations when the sections are too far apart, but I’d like to > avoid it whenever possible.**** > > ** ** > > What I meant in my previous message was that I’d have > RecordingMemoryManager use

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

> Cool, can you use clang 3.3 then? :) I can, but digging deeper I see that the compiler-rt sanitizer tests depend on just-built-clang for its object instrumentation. The next time the instrumentation changes, I'd expect those tests to break. If the lit tests that require -fsanitize were moved to the clang repo, then I think it'd be safe to build compiler-rt with clang 3.3 or gcc

Hi David, On Wed, Feb 12, 2014 at 5:22 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 12 Feb 2014, at 13:21, Alexey Samsonov <samsonov at google.com> wrote: > > > On Wed, Feb 12, 2014 at 4:56 PM, David Chisnall < > David.Chisnall at cl.cam.ac.uk> wrote: > >> Are you going to move the unwind library there as part of the >

In the same way that the core LLVM libraries have support routines for DWARF, I think that both mangling and demangling should be provided as well. I suspect that the 'Support' library is the best we have, although eventually we need to split this library up a bit. That's not really your problem though. The bigger problem is that we don't have any good way of sharing code between

Hi Andrew, Looks like RecordingMemoryManager in lli just calls malloc() and it would be strange to make assumptions (or enforce) that the difference between two returned pointers in 64-bit virtual address space will be fit into 32 bits. Can we do smth similar to what Adhemerval proposed (see the special case in processRelocationRef for ELF::R_PPC64_REL24 relocations)? On Tue, Jan 29, 2013 at

It's probably best to open a bug. -Andy From: Alexey Samsonov [mailto:samsonov at google.com] Sent: Thursday, January 31, 2013 12:27 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: Assertions in RuntimeDyldELF in ExecutionEngine/MCJIT tests On Wed, Jan 30, 2013 at 8:34 PM, Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>> wrote:

For me, UBsan fails with clang 3.2 and passes with clang 3.3. Using a fixed version allows you to build all clang/llvm/compiler-rt with one compiler. It simplifies the build process quite a bit. Also better for isolating regressions in compiler-rt, especially if you use git-bisect. Greg On May 29, 2013, at 12:30 AM, Alexey Samsonov <samsonov at google.com> wrote: > UBsan tests work

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

Okay, dropping gcc 4.4.3 makes sense. How do you feel about using clang 3.2 (and the upcoming 3.3) instead of tip-of-the-trunk clang? It looks like everything works great, but that you just need to make those UB tests 'unsupported' since they fail with "libclang_rt.ubsan was built without __int128 support". Thanks, Greg On Mon, May 27, 2013 at 12:36 AM, Alexey Samsonov

On Mon, Sep 30, 2013 at 7:48 PM, John Criswell <criswell at illinois.edu>wrote: > On 9/30/13 9:40 AM, Alexey Samsonov wrote: > > Hi llvmdev! > > There are cases when we want our instrumentation passes for Sanitizer > tools to insert llvm.memset.* calls (basically, we want to mark certain > region of user memory as (un)addressable by writing magic values for >

> What is the exact line you use to configure build tree, and the output you see? cmake ../.. \ -G Ninja \ -DCMAKE_INSTALL_PREFIX=ship \ -DCMAKE_BUILD_TYPE=Release \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_TARGETS_TO_BUILD=ARM \ -DLLVM_DEFAULT_TARGET_TRIPLE=arm-none-linux-gnueabi \ -DLLVM_TARGET_ARCH=arm-none-linux-gnueabi \ -DLLVM_LIT_ARGS=-v ninja check-all

Hi! On Fri, Mar 15, 2013 at 10:51 PM, Qun Fa <testforqunfa at gmail.com> wrote: > Thank you Alexey. > > I have tried to use Makefile. This will generate the correct symbols that > I need. > > Any idea on the schedule of adding CMake support to compiler-rt? > Starting from r177382 CMake on Linux should build the same profile compiler-rt library as Makefiles. >

> it assumes that compiler-rt is checked out to > llvm/projects/compiler-rt. Apparently, this is a problem. I have a patch for this ready. I'll send it to you and llvm-commits. Most of the tests pass with "make check-all" but the recently-added lsan tests are all failing. Do those fail for you as well? If so, can we XFAIL them for now and try to keep the "make

With comdats parts of the file might never be read. There are also multiple levels of cache and while all the relocations of a file will fit in ram, it is probably still more efficient to validate them as they are read. But I think (typing on a phone) that relocations are another case where the best is to have a more specific api: the only way the relocation is invalid from the perspective of

On Tue, Apr 16, 2013 at 8:31 PM, Michael Spencer <bigcheesegs at gmail.com>wrote: > On Tue, Apr 16, 2013 at 2:37 AM, Alexey Samsonov <samsonov at google.com>wrote: > >> Hi! >> >> TL;DR WDYT of adding zlib decompression capabilities to LLVMObject >> library? >> > >> ld.gold from GNU binutils has --compress-debug-sections=zlib option,