similar to: [LLVMdev] [MSan] false positive from Memory Sanitizer?

Hi, I've seen on the LLVM's Open Projet Page [1] an idea about using LLVM to generate native code in Valgrind. For what I know, Valgrind uses libVEX to translate native instructions into a bitcode, used to add the instrumentation and then translated back to native code for execution. Valgrind and LLVM are two tools that I use nearly every day. I'm also very interested in code

X is a matrix and F is a vector. F2 <- data.frame(cbind(X,F)) F2 V1 V2 V3 F 1 -0.250536332 -1.4755883 1.9580974 -2.136487 2 -0.009856084 0.4953269 0.5486092 -2.744482 3 -0.406962682 0.7729631 0.1861905 -2.891821 4 1.938780097 0.7469251 1.2537781 -1.212992 5 -0.332370358 1.1943637 0.7114278 -1.830441 modF<-formula(F ~ V1 + V2 + V3) #no error message

Hi, I receive the following error while I try to install rgl package: CC -xtarget=native64 -I/opt/R-2.8.1/lib/R/include -I/opt/SUNWhpc/HPC8.1/sun/include -DHAVE_PNG_H -I/usr/include/libpng12 -DHAVE_FREETYPE -Iext/ftgl -I/usr/sfw/include/freetype2 -I/usr/sfw/include -Iext -I/opt/SUNWhpc/HPC8.1/sun/include -I/usr/sfw/include -I/opt/csw/include -KPIC -O -c Background.cpp -o Background.o

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

Hi, I need to be able to use a special case list file containing thousands of entries (namely, a list of libc symbols, to be used when using DFSan with an uninstrumented libc). Initially I built the symbol list like this: fun:sym1=uninstrumented fun:sym2=uninstrumented fun:sym3=uninstrumented ... fun:sym6000=uninstrumented What I found was that, despite various bits of documentation [1,2], the

> Static runtime will only intercept calls from the main executable, but > not from any libraries. This may work for simple standalone programs, > but you may run into puzzling failures. What type of failures do you mean? Does the symbol mismatch break assumptions in the ASan runtime? It's easy to imagine, for example, ASan missing use-after-free bugs because the call to free() is

Reviving the discussion. The cool cmake-build of compiler-rt is not completely functional, but allows sanitizer runtimes to reuse LLVM code with almost no dirty hacks. Suppose I want to run call functions from LLVM libs (currently: LLVMDebugInfo, LLVMSupport) from sanitizer runtime. 1) I can simply include LLVM headers in sanitizer runtime, and it compiles and builds static asan runtime

Hi llvm-dev! I'm writing my master's thesis on sandboxing/isolation of plugins running in a multithreaded environment. These plugins run in a real-time environment where the cost of IPC/context switching and being at the scheduler's mercy is not an option. There can be a lot of plugin instances running and all have to perform some computations and return the result to the main thread

Am 18.02.2012 09:24, schrieb Blue Swirl: > On Wed, Feb 8, 2012 at 17:06, Roger Pau Monne <roger.pau@entel.upc.edu> wrote: >> libm is used in cutils.c, but the library was not specified >> when linking some binaries, throwing the following error: >> >> cutils.o: In function `strtosz_suffix_unit': >> /home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:354:

On Tue, Oct 7, 2014 at 2:51 PM, Peter Collingbourne <peter at pcc.me.uk> wrote: > Looks good, thanks! > > Can you write the test case, please? You probably have more experience > writing debug info tests than I do. > Sure - though how would I get the pre-dfsan .ll file to produce this behavior? I've tried compiling to a .ll file without dfsan, then feeling that .ll

I recently tried to enabled building llvm libraries with -Wl,-z,defs. The intention was to detect missing dependencies on ELF, so that we don't get into a situation where a .so builds, but the equivalent .dylib or .dll fails. This failed when building with msan because of undefined references to functions like __msan_memcpy. Unfortunately, I don't think elf linkers have a way of

On Tue, Oct 7, 2014 at 12:18 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Oct 7, 2014 at 12:10 PM, David Blaikie <dblaikie at gmail.com> wrote: > >> >> >> On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> >> wrote: >> >>> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote:

Hi, Porting msan to the Cavium T99 chip requires a VMA mapping of 4TB. The brute-force way of doing this would be by collecting memory segments that weren't mapped - from the results of the msan test harness - and creating mapped segments ranges. Lather, rinse, repeat until all the addressable segments are mapped in msan.h. But I was wondering if there isn't a more efficient way of

On 03.03.2018 13:10, David CARLIER via llvm-dev wrote: > Hi dear FreeBSD support, > > The turn of MemorySanitizer to get early support into FreeBSD. > > Kind regards. > I recommend to fix the failures in existing tests. Next enable MSan for sanitizer-common tests and fix the breaking tests on FreeBSD. How about TSan? -------------- next part -------------- A non-text

Hi dear FreeBSD support, The turn of MemorySanitizer to get early support into FreeBSD. Kind regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180303/253c2a4f/attachment.html>

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk> wrote: > On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote: > > Hi Peter, > > > > After discovering several bugs in ArgumentPromotion and > > DeadArgumentElimination where llvm::Functions were replaced with similar > > functions (with the same name) to transform their type

On Thu, Jan 22, 2015 at 2:33 AM, Evgeniy Stepanov <eugenis at google.com> wrote: > On Wed, Jan 21, 2015 at 8:46 PM, Rafael Espíndola > <rafael.espindola at gmail.com> wrote: > >> What about creating an msan interface DSO for the purposes of > satisfying -z > >> defs? The executable will always be searched first, so the interface DSO > >> could be

+eugenis@ On Sat, Sep 21, 2013 at 4:58 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Why does compiler-rt ship a shared object for ASan on Android instead > of a static library? Would statically linking ASan on Android at > least be safe for standalone executables? > > And if I'm wanting to use ASan in C++ code that is invoked from an > APK, can I statically

On 3 Mar 2018, at 13:10, David CARLIER via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi dear FreeBSD support, > > The turn of MemorySanitizer to get early support into FreeBSD. Thanks David, what are your plans? Sorry for slacking off on your other sanitizer reviews for FreeBSD. I have been busy on too many other things. :( -Dimitry -------------- next part

> What about creating an msan interface DSO for the purposes of satisfying -z > defs? The executable will always be searched first, so the interface DSO > could be empty or full of ud2a. I like the idea. The ideal solution would probably be for the linkers to have a --not-needed command line option that prevents the .so from going in the DT_NEEDED, but one with just stubs is probably