search for: radr

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

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

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 complet...

...re, I would expect the same failures with clang. Alex, could you 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...

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

...11:07 AM, Alexander Potapenko wrote: >> 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...

+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

...Alex, could you 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 -fs...

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

...tapenko wrote: >>> 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...

...c.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 upstrea...

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

...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 > &g...

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 firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

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

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

When compiling trunk using gcc 4.1.2 on linux/ppc64, I now see a warning that I don't remember seeing previously: llvm[2]: Compiling InlineSpiller.cpp for Release+Asserts build /src/llvm-trunk-dev/include/llvm/ADT/PointerIntPair.h: In member function ‘const PointerTy* llvm::PointerIntPair<PointerTy, IntBits, IntType, PtrTraits>::getAddrOfPointer() const [with PointerTy = void*, unsigned

...s strictness in the usage of filds and fists correct in the clang built-in assembler and, if so, is there any permutation of the configure test for the filds and fists mnemonics which clang would tolerate at -m64? Thanks in advance for any clarifications. Jack ps This is also filed as radr://21326888, "the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1".

...efix_re = re.compile(r"^(?:(RUN)| *(?:;|//|\#) *([A-Za-z0-9_-]+?)(?:-DAG|-LABEL|-NOT|-NEXT)?):(.*)$") self.check_prefix_re = re.compile(r"-?-check-prefix[= ]([^ ]+)\b") self.ignored_str = [ 'REQUIRES', 'XFAIL', 'rdar', 'radar', 'radr', 'FIXME', 'TODO', 'Todo', 'XXX', 'NOTE', 'Note', 'Bug', 'Fix', 'Shrink', 'http', 'vim', 'IMPORTANT', 'NB', 'WARNING' ] self.ignored_regs = [ re.compile(r&q...