search for: libsanitizer

...too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h, using MAC_INTERPOSE_FUNCTIONS on FSF gcc will require the missing blocks support to be implemented. I did a quick and dirty attempt to build libasan using libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm svn. The bootstrap chokes on... /bin/sh ../libtool --tag=CXX --mode=compile /sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/xg++ -B/sw/src/fink.build/gcc48-4.8.0-1000/darwin_objdir/./gcc/ -nostdinc++ -nostdinc++ -I/sw/src/fink....

...> > --kcc > > Kostya, > Unless I am misunderstanding the code in > asan/asan_intercepted_functions.h, > using MAC_INTERPOSE_FUNCTIONS on FSF gcc will require the missing blocks > support > to be implemented. I did a quick and dirty attempt to build libasan using > libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm > svn. > The bootstrap chokes on... > Alex is the expert in the OSX side of things, hopefully he can comment. But our situation wrt asan on OSX is as I see it: - mach_override does not work: we spent more time fighting with...

Hi, I am sending this bug report here because I can't register an account in bugzilla... gcc version: gcc-linaro-4.9-2014.09 (I checked also the main repo git, the code is the same) kernel: 2.6.37 "home/daniel/Downloads/.build/src/gcc-custom/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:675:43: error: 'EVIOCGPROP' was not declared in this scope" This happens when compiling with kernel 2.6.37 headers. #if EV_VERSION > (0x010000) unsigned IOCTL_EVIOCGKEYCODE_V2 = EVIOCGKEYCODE_V2; unsigned IOCTL_EVIOCGPROP = E...

...tya, > > Unless I am misunderstanding the code in > > asan/asan_intercepted_functions.h, > > using MAC_INTERPOSE_FUNCTIONS on FSF gcc will require the missing blocks > > support > > to be implemented. I did a quick and dirty attempt to build libasan using > > libsanitizer/asan/dynamic/asan_interceptors_dynamic.cc imported from llvm > > svn. > > The bootstrap chokes on... > > > > Alex is the expert in the OSX side of things, hopefully he can comment. > > But our situation wrt asan on OSX is as I see it: > - mach_override does not...

...gt; > >>> wrote: > >>>> > >>>> Nick, > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > >>>> I uploaded into the newly opened radr://12777299, "potential > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > >>>> it synced to the upstream llvm.org code). I have been helping > >>>> with the darwin build and testing -fsanitize=address against the > >...

On 30 November 2012 13:32, Alexander Potapenko <glider at google.com> wrote: > No, we are not going to use mach_inject. This isn't portable and may > be even harder to set up than mach_override. > The new ASan runtime will use the dylib interposition and will in fact > require DYLD_INSERT_LIBRARIES to work. However ASan already handles it > correctly itself: if the

...greement, so we could get cracking. >>> >>> >>> You mean you want a dynamic shadow offset on aarch64 as opposed to >>> fixed kAArch64_ShadowOffset64 (1UL << 36) one? >>> I think this is completely unnecessary, all you need to change is >>> libsanitizer internals IMNSHO, all that is needed is to make runtime >>> decisions during libasan initialization on the memory layout, and >>> also (because 39 bit VMA is too slow), dynamic decision whether to use >>> 32-bit or 64-bit allocator. See >>> https://gcc.gnu.org/b...

...t;howarth at bromo.med.uc.edu> >>> wrote: >>>> >>>> Nick, >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>>> I uploaded into the newly opened radr://12777299, "potential >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>>> have ported llvm.org's asan code into FSF gcc (and are keeping >>>> it synced to the upstream llvm.org code). I have been helping >>>> with the darwin build and testing -fsanitize=address against the >>>> complet...

...:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >> wrote: >>> >>> Nick, >>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>> I uploaded into the newly opened radr://12777299, "potential >>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>> have ported llvm.org's asan code into FSF gcc (and are keeping >>> it synced to the upstream llvm.org code). I have been helping >>> with the darwin build and testing -fsanitize=address against the >>> complete FSF gcc testsu...

On Tue, Dec 04, 2012 at 09:46:09AM -0800, Alexander Potapenko wrote: > +kledzik at apple.com > The dynamic runtime is using dylib interposition (google for > "__DATA,__interpose). > If I'm understanding correctly (Nick, can you please confirm this?) > this allows to interpose the function regardless of the two-level > namespace. > The support for dynamic runtime in

Nick, Can you take a quick look at the asan_eh_bug.tar.bz testcase I uploaded into the newly opened radr://12777299, "potential pthread/eh bug exposed by libsanitizer". The FSF gcc developers have ported llvm.org's asan code into FSF gcc (and are keeping it synced to the upstream llvm.org code). I have been helping with the darwin build and testing -fsanitize=address against the complete FSF gcc testsuite. This seems to have exposed a potential bug in p...

...please take a look? --kcc On Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > Nick, > Can you take a quick look at the asan_eh_bug.tar.bz testcase > I uploaded into the newly opened radr://12777299, "potential > pthread/eh bug exposed by libsanitizer". The FSF gcc developers > have ported llvm.org's asan code into FSF gcc (and are keeping > it synced to the upstream llvm.org code). I have been helping > with the darwin build and testing -fsanitize=address against the > complete FSF gcc testsuite. This seems to have exposed...

...t;>>> >> > >>>> Nick, >> > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >> > >>>> I uploaded into the newly opened radr://12777299, "potential >> > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >> > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping >> > >>>> it synced to the upstream llvm.org code). I have been helping >> > >>>> with the darwin build and testing -fsanitize=ad...

...:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> >> wrote: >>> >>> Nick, >>> Can you take a quick look at the asan_eh_bug.tar.bz testcase >>> I uploaded into the newly opened radr://12777299, "potential >>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >>> have ported llvm.org's asan code into FSF gcc (and are keeping >>> it synced to the upstream llvm.org code). I have been helping >>> with the darwin build and testing -fsanitize=address against the >>> complete FSF gcc testsu...

+kledzik at apple.com The dynamic runtime is using dylib interposition (google for "__DATA,__interpose). If I'm understanding correctly (Nick, can you please confirm this?) this allows to interpose the function regardless of the two-level namespace. The support for dynamic runtime in ASan is almost there. But the new interposition method has revealed some issues with the allocator which

...n Thu, Nov 29, 2012 at 9:55 PM, Jack Howarth <howarth at bromo.med.uc.edu> > wrote: >> >> Nick, >> Can you take a quick look at the asan_eh_bug.tar.bz testcase >> I uploaded into the newly opened radr://12777299, "potential >> pthread/eh bug exposed by libsanitizer". The FSF gcc developers >> have ported llvm.org's asan code into FSF gcc (and are keeping >> it synced to the upstream llvm.org code). I have been helping >> with the darwin build and testing -fsanitize=address against the >> complete FSF gcc testsuite. This seems...

...te: > > >>>> > > >>>> Nick, > > >>>> Can you take a quick look at the asan_eh_bug.tar.bz testcase > > >>>> I uploaded into the newly opened radr://12777299, "potential > > >>>> pthread/eh bug exposed by libsanitizer". The FSF gcc developers > > >>>> have ported llvm.org's asan code into FSF gcc (and are keeping > > >>>> it synced to the upstream llvm.org code). I have been helping > > >>>> with the darwin build and testing -fsanitize=address agains...

...es. I'd like to know if >> everyone is in agreement, so we could get cracking. > > You mean you want a dynamic shadow offset on aarch64 as opposed to > fixed kAArch64_ShadowOffset64 (1UL << 36) one? > I think this is completely unnecessary, all you need to change is > libsanitizer internals IMNSHO, all that is needed is to make runtime > decisions during libasan initialization on the memory layout, and > also (because 39 bit VMA is too slow), dynamic decision whether to use > 32-bit or 64-bit allocator. See > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 &g...

...D, 0x05, 0x00, 0x00, 0x00, 0x00} }, // lea $imm(%rip),%rax { 0x3, {0xFF, 0xFF, 0xFF}, {0x0F, 0xBE, 0xCE} }, // movsbl, %dh, %ecx { 0x3, {0xFF, 0xFF, 0x00}, {0xFF, 0x77, 0x00} }, // pushq $imm(%rdi) { 0x2, {0xFF, 0xFF}, {0xDB, 0xE3} }, // fninit which produced a usable libsanitizer on x86_64 and i386 darwin. Perhaps these instances of lea aren't a problem on llvm, but I thought I ought to point this fix out as a potential change for the llvm 3.2 release. Jack

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start