* [PATCH] Do not build libsanitizer also for powerpc*-*-linux* [not found] <1401100995.27542.ezmlm@gcc.gnu.org> @ 2014-05-26 10:53 ` Arseny Solokha 2014-05-26 11:29 ` Konstantin Serebryany 2014-05-28 7:36 ` Thomas Schwinge 0 siblings, 2 replies; 25+ messages in thread From: Arseny Solokha @ 2014-05-26 10:53 UTC (permalink / raw) To: gcc-patches [-- Attachment #1: Type: text/plain, Size: 437 bytes --] Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The proposed patch disables building libsanitizer for powerpc*-*-linux* in addition to already disabled powerpc*le-*-linux* until the smarter solution will emerge. The actual issue preventing ASAN from porting to PPC seems to be inability to retrieve values of PC and BP on this architecture. [-- Attachment #2: libsanitizer.patch --] [-- Type: text/x-patch, Size: 381 bytes --] --- gcc-4.10-20140525/libsanitizer/configure.tgt~ 2014-05-26 17:59:21.224116974 +0800 +++ gcc-4.10-20140525/libsanitizer/configure.tgt 2014-05-26 18:00:03.048478781 +0800 @@ -26,11 +26,9 @@ LSAN_SUPPORTED=yes fi ;; - powerpc*le-*-linux*) + powerpc*-*-linux* | powerpc*le-*-linux*) UNSUPPORTED=1 ;; - powerpc*-*-linux*) - ;; sparc*-*-linux*) ;; arm*-*-linux*) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-26 10:53 ` [PATCH] Do not build libsanitizer also for powerpc*-*-linux* Arseny Solokha @ 2014-05-26 11:29 ` Konstantin Serebryany 2014-05-28 7:36 ` Thomas Schwinge 1 sibling, 0 replies; 25+ messages in thread From: Konstantin Serebryany @ 2014-05-26 11:29 UTC (permalink / raw) To: Arseny Solokha; +Cc: GCC Patches On Mon, May 26, 2014 at 2:53 PM, Arseny Solokha <asolokha@gmx.com> wrote: > Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it > impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. The > proposed patch disables building libsanitizer for powerpc*-*-linux* in addition > to already disabled powerpc*le-*-linux* until the smarter solution will emerge. > > The actual issue preventing ASAN from porting to PPC seems to be inability to > retrieve values of PC and BP on this architecture. I agree with disabling asan on any platform that is not supported upstream. You still may need someone else's (Jakub's?) approval for this. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-26 10:53 ` [PATCH] Do not build libsanitizer also for powerpc*-*-linux* Arseny Solokha 2014-05-26 11:29 ` Konstantin Serebryany @ 2014-05-28 7:36 ` Thomas Schwinge 2014-05-29 19:08 ` Peter Bergner 1 sibling, 1 reply; 25+ messages in thread From: Thomas Schwinge @ 2014-05-28 7:36 UTC (permalink / raw) To: Arseny Solokha, jakub, dodji, kcc, dvyukov; +Cc: gcc-patches, bergner [-- Attachment #1: Type: text/plain, Size: 1321 bytes --] Hi! On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha <asolokha@gmx.com> wrote: > Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it > impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. I hit this, too. > The > proposed patch disables building libsanitizer for powerpc*-*-linux* in addition > to already disabled powerpc*le-*-linux* until the smarter solution will emerge. > > The actual issue preventing ASAN from porting to PPC seems to be inability to > retrieve values of PC and BP on this architecture. This is being discussed in the thread at <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that has been resolved, I do agree to check in the following patch (and have successfully tested it, but cannot formally approve it for commit; thus copying the libsanitizer maintainers): > --- gcc-4.10-20140525/libsanitizer/configure.tgt~ 2014-05-26 17:59:21.224116974 +0800 > +++ gcc-4.10-20140525/libsanitizer/configure.tgt 2014-05-26 18:00:03.048478781 +0800 > @@ -26,11 +26,9 @@ > LSAN_SUPPORTED=yes > fi > ;; > - powerpc*le-*-linux*) > + powerpc*-*-linux* | powerpc*le-*-linux*) > UNSUPPORTED=1 > ;; > - powerpc*-*-linux*) > - ;; > sparc*-*-linux*) > ;; > arm*-*-linux*) Grüße, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-28 7:36 ` Thomas Schwinge @ 2014-05-29 19:08 ` Peter Bergner 2014-05-30 13:09 ` Peter Bergner 0 siblings, 1 reply; 25+ messages in thread From: Peter Bergner @ 2014-05-29 19:08 UTC (permalink / raw) To: Thomas Schwinge; +Cc: Arseny Solokha, jakub, dodji, kcc, dvyukov, gcc-patches On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: > Hi! > > On Mon, 26 May 2014 18:53:22 +0800, Arseny Solokha <asolokha@gmx.com> wrote: > > Recent changes in GetPcSpBp() (libsanitizer/asan/asan_linux.cc) made it > > impossible to build 4.10.0-alpha20140525 snapshot for powerpc targets. > > I hit this, too. > > > The > > proposed patch disables building libsanitizer for powerpc*-*-linux* in addition > > to already disabled powerpc*le-*-linux* until the smarter solution will emerge. > > > > The actual issue preventing ASAN from porting to PPC seems to be inability to > > retrieve values of PC and BP on this architecture. > > This is being discussed in the thread at > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that > has been resolved, I do agree to check in the following patch (and have > successfully tested it, but cannot formally approve it for commit; thus > copying the libsanitizer maintainers): The re-enablement patch was submitted to the llvm mailing list here: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html Once that is committed and merged into gcc, we can re-enable building libsanitizer for powerpc*-linux. Peter ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-29 19:08 ` Peter Bergner @ 2014-05-30 13:09 ` Peter Bergner 2014-05-30 13:49 ` Jakub Jelinek 0 siblings, 1 reply; 25+ messages in thread From: Peter Bergner @ 2014-05-30 13:09 UTC (permalink / raw) To: Thomas Schwinge; +Cc: Arseny Solokha, jakub, dodji, kcc, dvyukov, gcc-patches On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: > > This is being discussed in the thread at > > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that > > has been resolved, I do agree to check in the following patch (and have > > successfully tested it, but cannot formally approve it for commit; thus > > copying the libsanitizer maintainers): > > The re-enablement patch was submitted to the llvm mailing list here: > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html > > Once that is committed and merged into gcc, we can re-enable building > libsanitizer for powerpc*-linux. Ok, it was committed upstream as revision 209879. Kostya, can we get this merged into gcc trunk and powerpc*-linux re-enabled again? Thanks. Peter ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-30 13:09 ` Peter Bergner @ 2014-05-30 13:49 ` Jakub Jelinek 2014-05-30 18:02 ` Konstantin Serebryany ` (2 more replies) 0 siblings, 3 replies; 25+ messages in thread From: Jakub Jelinek @ 2014-05-30 13:49 UTC (permalink / raw) To: Peter Bergner Cc: Thomas Schwinge, Arseny Solokha, dodji, kcc, dvyukov, gcc-patches On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote: > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: > > > This is being discussed in the thread at > > > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that > > > has been resolved, I do agree to check in the following patch (and have > > > successfully tested it, but cannot formally approve it for commit; thus > > > copying the libsanitizer maintainers): > > > > The re-enablement patch was submitted to the llvm mailing list here: > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html > > > > Once that is committed and merged into gcc, we can re-enable building > > libsanitizer for powerpc*-linux. > > Ok, it was committed upstream as revision 209879. Kostya, can we get > this merged into gcc trunk and powerpc*-linux re-enabled again? Thanks. I've cherry-picked the two upstream commits and after testing on x86_64-linux/i686-linux committed to trunk. 2014-05-30 Jakub Jelinek <jakub@redhat.com> * sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream r209879. * sanitizer_common/sanitizer_common.h: Likewise. * asan/asan_mapping.h: Likewise. * asan/asan_linux.cc: Likewise. * tsan/tsan_mman.cc: Cherry pick upstream r209744. * sanitizer_common/sanitizer_allocator.h: Likewise. --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209878) +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209879) @@ -18,11 +18,13 @@ namespace __sanitizer { uptr StackTrace::GetPreviousInstructionPc(uptr pc) { -#ifdef __arm__ +#if defined(__arm__) // Cancel Thumb bit. pc = pc & (~1); -#endif -#if defined(__sparc__) +#elif defined(__powerpc__) || defined(__powerpc64__) + // PCs are always 4 byte aligned. + return pc - 4; +#elif defined(__sparc__) return pc - 8; #else return pc - 1; --- libsanitizer/sanitizer_common/sanitizer_common.h (revision 209878) +++ libsanitizer/sanitizer_common/sanitizer_common.h (revision 209879) @@ -28,7 +28,11 @@ struct StackTrace; const uptr kWordSize = SANITIZER_WORDSIZE / 8; const uptr kWordSizeInBits = 8 * kWordSize; -const uptr kCacheLineSize = 64; +#if defined(__powerpc__) || defined(__powerpc64__) + const uptr kCacheLineSize = 128; +#else + const uptr kCacheLineSize = 64; +#endif const uptr kMaxPathLength = 512; --- libsanitizer/asan/asan_mapping.h (revision 209878) +++ libsanitizer/asan/asan_mapping.h (revision 209879) @@ -87,6 +87,7 @@ static const u64 kDefaultShadowOffset64 static const u64 kDefaultShort64bitShadowOffset = 0x7FFF8000; // < 2G. static const u64 kAArch64_ShadowOffset64 = 1ULL << 36; static const u64 kMIPS32_ShadowOffset32 = 0x0aaa8000; +static const u64 kPPC64_ShadowOffset64 = 1ULL << 41; static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30; // 0x40000000 static const u64 kFreeBSD_ShadowOffset64 = 1ULL << 46; // 0x400000000000 @@ -109,6 +110,8 @@ static const u64 kFreeBSD_ShadowOffset64 # else # if defined(__aarch64__) # define SHADOW_OFFSET kAArch64_ShadowOffset64 +# elif defined(__powerpc64__) +# define SHADOW_OFFSET kPPC64_ShadowOffset64 # elif SANITIZER_FREEBSD # define SHADOW_OFFSET kFreeBSD_ShadowOffset64 # elif SANITIZER_MAC --- libsanitizer/asan/asan_linux.cc (revision 209878) +++ libsanitizer/asan/asan_linux.cc (revision 209879) @@ -188,6 +188,13 @@ void GetPcSpBp(void *context, uptr *pc, *bp = ucontext->uc_mcontext.gregs[REG_EBP]; *sp = ucontext->uc_mcontext.gregs[REG_ESP]; # endif +#elif defined(__powerpc__) || defined(__powerpc64__) + ucontext_t *ucontext = (ucontext_t*)context; + *pc = ucontext->uc_mcontext.regs->nip; + *sp = ucontext->uc_mcontext.regs->gpr[PT_R1]; + // The powerpc{,64}-linux ABIs do not specify r31 as the frame + // pointer, but GCC always uses r31 when we need a frame pointer. + *bp = ucontext->uc_mcontext.regs->gpr[PT_R31]; #elif defined(__sparc__) ucontext_t *ucontext = (ucontext_t*)context; uptr *stk_ptr; --- libsanitizer/tsan/tsan_mman.cc (revision 209743) +++ libsanitizer/tsan/tsan_mman.cc (revision 209744) @@ -217,19 +217,15 @@ using namespace __tsan; extern "C" { uptr __tsan_get_current_allocated_bytes() { - u64 stats[AllocatorStatCount]; + uptr stats[AllocatorStatCount]; allocator()->GetStats(stats); - u64 m = stats[AllocatorStatMalloced]; - u64 f = stats[AllocatorStatFreed]; - return m >= f ? m - f : 1; + return stats[AllocatorStatAllocated]; } uptr __tsan_get_heap_size() { - u64 stats[AllocatorStatCount]; + uptr stats[AllocatorStatCount]; allocator()->GetStats(stats); - u64 m = stats[AllocatorStatMmapped]; - u64 f = stats[AllocatorStatUnmapped]; - return m >= f ? m - f : 1; + return stats[AllocatorStatMapped]; } uptr __tsan_get_free_bytes() { --- libsanitizer/sanitizer_common/sanitizer_allocator.h (revision 209743) +++ libsanitizer/sanitizer_common/sanitizer_allocator.h (revision 209744) @@ -198,14 +198,12 @@ template<class SizeClassAllocator> struc // Memory allocator statistics enum AllocatorStat { - AllocatorStatMalloced, - AllocatorStatFreed, - AllocatorStatMmapped, - AllocatorStatUnmapped, + AllocatorStatAllocated, + AllocatorStatMapped, AllocatorStatCount }; -typedef u64 AllocatorStatCounters[AllocatorStatCount]; +typedef uptr AllocatorStatCounters[AllocatorStatCount]; // Per-thread stats, live in per-thread cache. class AllocatorStats { @@ -214,16 +212,21 @@ class AllocatorStats { internal_memset(this, 0, sizeof(*this)); } - void Add(AllocatorStat i, u64 v) { + void Add(AllocatorStat i, uptr v) { v += atomic_load(&stats_[i], memory_order_relaxed); atomic_store(&stats_[i], v, memory_order_relaxed); } - void Set(AllocatorStat i, u64 v) { + void Sub(AllocatorStat i, uptr v) { + v = atomic_load(&stats_[i], memory_order_relaxed) - v; atomic_store(&stats_[i], v, memory_order_relaxed); } - u64 Get(AllocatorStat i) const { + void Set(AllocatorStat i, uptr v) { + atomic_store(&stats_[i], v, memory_order_relaxed); + } + + uptr Get(AllocatorStat i) const { return atomic_load(&stats_[i], memory_order_relaxed); } @@ -231,7 +234,7 @@ class AllocatorStats { friend class AllocatorGlobalStats; AllocatorStats *next_; AllocatorStats *prev_; - atomic_uint64_t stats_[AllocatorStatCount]; + atomic_uintptr_t stats_[AllocatorStatCount]; }; // Global stats, used for aggregation and querying. @@ -260,7 +263,7 @@ class AllocatorGlobalStats : public Allo } void Get(AllocatorStatCounters s) const { - internal_memset(s, 0, AllocatorStatCount * sizeof(u64)); + internal_memset(s, 0, AllocatorStatCount * sizeof(uptr)); SpinMutexLock l(&mu_); const AllocatorStats *stats = this; for (;;) { @@ -270,6 +273,9 @@ class AllocatorGlobalStats : public Allo if (stats == this) break; } + // All stats must be positive. + for (int i = 0; i < AllocatorStatCount; i++) + s[i] = ((sptr)s[i]) > 0 ? s[i] : 1; } private: @@ -522,7 +528,7 @@ class SizeClassAllocator64 { map_size += kUserMapSize; CHECK_GE(region->mapped_user + map_size, end_idx); MapWithCallback(region_beg + region->mapped_user, map_size); - stat->Add(AllocatorStatMmapped, map_size); + stat->Add(AllocatorStatMapped, map_size); region->mapped_user += map_size; } uptr total_count = (region->mapped_user - beg_idx - size) @@ -841,7 +847,7 @@ class SizeClassAllocator32 { uptr res = reinterpret_cast<uptr>(MmapAlignedOrDie(kRegionSize, kRegionSize, "SizeClassAllocator32")); MapUnmapCallback().OnMap(res, kRegionSize); - stat->Add(AllocatorStatMmapped, kRegionSize); + stat->Add(AllocatorStatMapped, kRegionSize); CHECK_EQ(0U, (res & (kRegionSize - 1))); possible_regions.set(ComputeRegionId(res), static_cast<u8>(class_id)); return res; @@ -907,7 +913,7 @@ struct SizeClassAllocatorLocalCache { void *Allocate(SizeClassAllocator *allocator, uptr class_id) { CHECK_NE(class_id, 0UL); CHECK_LT(class_id, kNumClasses); - stats_.Add(AllocatorStatMalloced, SizeClassMap::Size(class_id)); + stats_.Add(AllocatorStatAllocated, SizeClassMap::Size(class_id)); PerClass *c = &per_class_[class_id]; if (UNLIKELY(c->count == 0)) Refill(allocator, class_id); @@ -922,7 +928,7 @@ struct SizeClassAllocatorLocalCache { // If the first allocator call on a new thread is a deallocation, then // max_count will be zero, leading to check failure. InitCache(); - stats_.Add(AllocatorStatFreed, SizeClassMap::Size(class_id)); + stats_.Sub(AllocatorStatAllocated, SizeClassMap::Size(class_id)); PerClass *c = &per_class_[class_id]; CHECK_NE(c->max_count, 0UL); if (UNLIKELY(c->count == c->max_count)) @@ -1033,8 +1039,8 @@ class LargeMmapAllocator { stats.currently_allocated += map_size; stats.max_allocated = Max(stats.max_allocated, stats.currently_allocated); stats.by_size_log[size_log]++; - stat->Add(AllocatorStatMalloced, map_size); - stat->Add(AllocatorStatMmapped, map_size); + stat->Add(AllocatorStatAllocated, map_size); + stat->Add(AllocatorStatMapped, map_size); } return reinterpret_cast<void*>(res); } @@ -1052,8 +1058,8 @@ class LargeMmapAllocator { chunks_sorted_ = false; stats.n_frees++; stats.currently_allocated -= h->map_size; - stat->Add(AllocatorStatFreed, h->map_size); - stat->Add(AllocatorStatUnmapped, h->map_size); + stat->Sub(AllocatorStatAllocated, h->map_size); + stat->Sub(AllocatorStatMapped, h->map_size); } MapUnmapCallback().OnUnmap(h->map_beg, h->map_size); UnmapOrDie(reinterpret_cast<void*>(h->map_beg), h->map_size); Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-30 13:49 ` Jakub Jelinek @ 2014-05-30 18:02 ` Konstantin Serebryany 2014-05-31 19:53 ` Peter Bergner 2014-06-02 6:22 ` Yury Gribov 2 siblings, 0 replies; 25+ messages in thread From: Konstantin Serebryany @ 2014-05-30 18:02 UTC (permalink / raw) To: Jakub Jelinek Cc: Peter Bergner, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches Thanks Jakub! Looks like there is not rush with another merge now. --kcc On Fri, May 30, 2014 at 5:49 PM, Jakub Jelinek <jakub@redhat.com> wrote: > On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote: >> On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: >> > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: >> > > This is being discussed in the thread at >> > > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that >> > > has been resolved, I do agree to check in the following patch (and have >> > > successfully tested it, but cannot formally approve it for commit; thus >> > > copying the libsanitizer maintainers): >> > >> > The re-enablement patch was submitted to the llvm mailing list here: >> > >> > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html >> > >> > Once that is committed and merged into gcc, we can re-enable building >> > libsanitizer for powerpc*-linux. >> >> Ok, it was committed upstream as revision 209879. Kostya, can we get >> this merged into gcc trunk and powerpc*-linux re-enabled again? Thanks. > > I've cherry-picked the two upstream commits and after testing on > x86_64-linux/i686-linux committed to trunk. > > 2014-05-30 Jakub Jelinek <jakub@redhat.com> > > * sanitizer_common/sanitizer_stacktrace.cc: Cherry pick upstream > r209879. > * sanitizer_common/sanitizer_common.h: Likewise. > * asan/asan_mapping.h: Likewise. > * asan/asan_linux.cc: Likewise. > * tsan/tsan_mman.cc: Cherry pick upstream r209744. > * sanitizer_common/sanitizer_allocator.h: Likewise. > > --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209878) > +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209879) > @@ -18,11 +18,13 @@ > namespace __sanitizer { > > uptr StackTrace::GetPreviousInstructionPc(uptr pc) { > -#ifdef __arm__ > +#if defined(__arm__) > // Cancel Thumb bit. > pc = pc & (~1); > -#endif > -#if defined(__sparc__) > +#elif defined(__powerpc__) || defined(__powerpc64__) > + // PCs are always 4 byte aligned. > + return pc - 4; > +#elif defined(__sparc__) > return pc - 8; > #else > return pc - 1; > --- libsanitizer/sanitizer_common/sanitizer_common.h (revision 209878) > +++ libsanitizer/sanitizer_common/sanitizer_common.h (revision 209879) > @@ -28,7 +28,11 @@ struct StackTrace; > const uptr kWordSize = SANITIZER_WORDSIZE / 8; > const uptr kWordSizeInBits = 8 * kWordSize; > > -const uptr kCacheLineSize = 64; > +#if defined(__powerpc__) || defined(__powerpc64__) > + const uptr kCacheLineSize = 128; > +#else > + const uptr kCacheLineSize = 64; > +#endif > > const uptr kMaxPathLength = 512; > > --- libsanitizer/asan/asan_mapping.h (revision 209878) > +++ libsanitizer/asan/asan_mapping.h (revision 209879) > @@ -87,6 +87,7 @@ static const u64 kDefaultShadowOffset64 > static const u64 kDefaultShort64bitShadowOffset = 0x7FFF8000; // < 2G. > static const u64 kAArch64_ShadowOffset64 = 1ULL << 36; > static const u64 kMIPS32_ShadowOffset32 = 0x0aaa8000; > +static const u64 kPPC64_ShadowOffset64 = 1ULL << 41; > static const u64 kFreeBSD_ShadowOffset32 = 1ULL << 30; // 0x40000000 > static const u64 kFreeBSD_ShadowOffset64 = 1ULL << 46; // 0x400000000000 > > @@ -109,6 +110,8 @@ static const u64 kFreeBSD_ShadowOffset64 > # else > # if defined(__aarch64__) > # define SHADOW_OFFSET kAArch64_ShadowOffset64 > +# elif defined(__powerpc64__) > +# define SHADOW_OFFSET kPPC64_ShadowOffset64 > # elif SANITIZER_FREEBSD > # define SHADOW_OFFSET kFreeBSD_ShadowOffset64 > # elif SANITIZER_MAC > --- libsanitizer/asan/asan_linux.cc (revision 209878) > +++ libsanitizer/asan/asan_linux.cc (revision 209879) > @@ -188,6 +188,13 @@ void GetPcSpBp(void *context, uptr *pc, > *bp = ucontext->uc_mcontext.gregs[REG_EBP]; > *sp = ucontext->uc_mcontext.gregs[REG_ESP]; > # endif > +#elif defined(__powerpc__) || defined(__powerpc64__) > + ucontext_t *ucontext = (ucontext_t*)context; > + *pc = ucontext->uc_mcontext.regs->nip; > + *sp = ucontext->uc_mcontext.regs->gpr[PT_R1]; > + // The powerpc{,64}-linux ABIs do not specify r31 as the frame > + // pointer, but GCC always uses r31 when we need a frame pointer. > + *bp = ucontext->uc_mcontext.regs->gpr[PT_R31]; > #elif defined(__sparc__) > ucontext_t *ucontext = (ucontext_t*)context; > uptr *stk_ptr; > --- libsanitizer/tsan/tsan_mman.cc (revision 209743) > +++ libsanitizer/tsan/tsan_mman.cc (revision 209744) > @@ -217,19 +217,15 @@ using namespace __tsan; > > extern "C" { > uptr __tsan_get_current_allocated_bytes() { > - u64 stats[AllocatorStatCount]; > + uptr stats[AllocatorStatCount]; > allocator()->GetStats(stats); > - u64 m = stats[AllocatorStatMalloced]; > - u64 f = stats[AllocatorStatFreed]; > - return m >= f ? m - f : 1; > + return stats[AllocatorStatAllocated]; > } > > uptr __tsan_get_heap_size() { > - u64 stats[AllocatorStatCount]; > + uptr stats[AllocatorStatCount]; > allocator()->GetStats(stats); > - u64 m = stats[AllocatorStatMmapped]; > - u64 f = stats[AllocatorStatUnmapped]; > - return m >= f ? m - f : 1; > + return stats[AllocatorStatMapped]; > } > > uptr __tsan_get_free_bytes() { > --- libsanitizer/sanitizer_common/sanitizer_allocator.h (revision 209743) > +++ libsanitizer/sanitizer_common/sanitizer_allocator.h (revision 209744) > @@ -198,14 +198,12 @@ template<class SizeClassAllocator> struc > > // Memory allocator statistics > enum AllocatorStat { > - AllocatorStatMalloced, > - AllocatorStatFreed, > - AllocatorStatMmapped, > - AllocatorStatUnmapped, > + AllocatorStatAllocated, > + AllocatorStatMapped, > AllocatorStatCount > }; > > -typedef u64 AllocatorStatCounters[AllocatorStatCount]; > +typedef uptr AllocatorStatCounters[AllocatorStatCount]; > > // Per-thread stats, live in per-thread cache. > class AllocatorStats { > @@ -214,16 +212,21 @@ class AllocatorStats { > internal_memset(this, 0, sizeof(*this)); > } > > - void Add(AllocatorStat i, u64 v) { > + void Add(AllocatorStat i, uptr v) { > v += atomic_load(&stats_[i], memory_order_relaxed); > atomic_store(&stats_[i], v, memory_order_relaxed); > } > > - void Set(AllocatorStat i, u64 v) { > + void Sub(AllocatorStat i, uptr v) { > + v = atomic_load(&stats_[i], memory_order_relaxed) - v; > atomic_store(&stats_[i], v, memory_order_relaxed); > } > > - u64 Get(AllocatorStat i) const { > + void Set(AllocatorStat i, uptr v) { > + atomic_store(&stats_[i], v, memory_order_relaxed); > + } > + > + uptr Get(AllocatorStat i) const { > return atomic_load(&stats_[i], memory_order_relaxed); > } > > @@ -231,7 +234,7 @@ class AllocatorStats { > friend class AllocatorGlobalStats; > AllocatorStats *next_; > AllocatorStats *prev_; > - atomic_uint64_t stats_[AllocatorStatCount]; > + atomic_uintptr_t stats_[AllocatorStatCount]; > }; > > // Global stats, used for aggregation and querying. > @@ -260,7 +263,7 @@ class AllocatorGlobalStats : public Allo > } > > void Get(AllocatorStatCounters s) const { > - internal_memset(s, 0, AllocatorStatCount * sizeof(u64)); > + internal_memset(s, 0, AllocatorStatCount * sizeof(uptr)); > SpinMutexLock l(&mu_); > const AllocatorStats *stats = this; > for (;;) { > @@ -270,6 +273,9 @@ class AllocatorGlobalStats : public Allo > if (stats == this) > break; > } > + // All stats must be positive. > + for (int i = 0; i < AllocatorStatCount; i++) > + s[i] = ((sptr)s[i]) > 0 ? s[i] : 1; > } > > private: > @@ -522,7 +528,7 @@ class SizeClassAllocator64 { > map_size += kUserMapSize; > CHECK_GE(region->mapped_user + map_size, end_idx); > MapWithCallback(region_beg + region->mapped_user, map_size); > - stat->Add(AllocatorStatMmapped, map_size); > + stat->Add(AllocatorStatMapped, map_size); > region->mapped_user += map_size; > } > uptr total_count = (region->mapped_user - beg_idx - size) > @@ -841,7 +847,7 @@ class SizeClassAllocator32 { > uptr res = reinterpret_cast<uptr>(MmapAlignedOrDie(kRegionSize, kRegionSize, > "SizeClassAllocator32")); > MapUnmapCallback().OnMap(res, kRegionSize); > - stat->Add(AllocatorStatMmapped, kRegionSize); > + stat->Add(AllocatorStatMapped, kRegionSize); > CHECK_EQ(0U, (res & (kRegionSize - 1))); > possible_regions.set(ComputeRegionId(res), static_cast<u8>(class_id)); > return res; > @@ -907,7 +913,7 @@ struct SizeClassAllocatorLocalCache { > void *Allocate(SizeClassAllocator *allocator, uptr class_id) { > CHECK_NE(class_id, 0UL); > CHECK_LT(class_id, kNumClasses); > - stats_.Add(AllocatorStatMalloced, SizeClassMap::Size(class_id)); > + stats_.Add(AllocatorStatAllocated, SizeClassMap::Size(class_id)); > PerClass *c = &per_class_[class_id]; > if (UNLIKELY(c->count == 0)) > Refill(allocator, class_id); > @@ -922,7 +928,7 @@ struct SizeClassAllocatorLocalCache { > // If the first allocator call on a new thread is a deallocation, then > // max_count will be zero, leading to check failure. > InitCache(); > - stats_.Add(AllocatorStatFreed, SizeClassMap::Size(class_id)); > + stats_.Sub(AllocatorStatAllocated, SizeClassMap::Size(class_id)); > PerClass *c = &per_class_[class_id]; > CHECK_NE(c->max_count, 0UL); > if (UNLIKELY(c->count == c->max_count)) > @@ -1033,8 +1039,8 @@ class LargeMmapAllocator { > stats.currently_allocated += map_size; > stats.max_allocated = Max(stats.max_allocated, stats.currently_allocated); > stats.by_size_log[size_log]++; > - stat->Add(AllocatorStatMalloced, map_size); > - stat->Add(AllocatorStatMmapped, map_size); > + stat->Add(AllocatorStatAllocated, map_size); > + stat->Add(AllocatorStatMapped, map_size); > } > return reinterpret_cast<void*>(res); > } > @@ -1052,8 +1058,8 @@ class LargeMmapAllocator { > chunks_sorted_ = false; > stats.n_frees++; > stats.currently_allocated -= h->map_size; > - stat->Add(AllocatorStatFreed, h->map_size); > - stat->Add(AllocatorStatUnmapped, h->map_size); > + stat->Sub(AllocatorStatAllocated, h->map_size); > + stat->Sub(AllocatorStatMapped, h->map_size); > } > MapUnmapCallback().OnUnmap(h->map_beg, h->map_size); > UnmapOrDie(reinterpret_cast<void*>(h->map_beg), h->map_size); > > > Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-30 13:49 ` Jakub Jelinek 2014-05-30 18:02 ` Konstantin Serebryany @ 2014-05-31 19:53 ` Peter Bergner 2014-06-02 4:54 ` Konstantin Serebryany 2014-06-02 6:22 ` Yury Gribov 2 siblings, 1 reply; 25+ messages in thread From: Peter Bergner @ 2014-05-31 19:53 UTC (permalink / raw) To: Jakub Jelinek Cc: Thomas Schwinge, Arseny Solokha, dodji, kcc, dvyukov, gcc-patches, Paolo Carlini On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote: > On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote: > > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: > > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: > > > > This is being discussed in the thread at > > > > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that > > > > has been resolved, I do agree to check in the following patch (and have > > > > successfully tested it, but cannot formally approve it for commit; thus > > > > copying the libsanitizer maintainers): > > > > > > The re-enablement patch was submitted to the llvm mailing list here: > > > > > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html > > > > > > Once that is committed and merged into gcc, we can re-enable building > > > libsanitizer for powerpc*-linux. > > > > Ok, it was committed upstream as revision 209879. Kostya, can we get > > this merged into gcc trunk and powerpc*-linux re-enabled again? Thanks. > > I've cherry-picked the two upstream commits and after testing on > x86_64-linux/i686-linux committed to trunk. Great, thanks! I bootstrapped and ran the asan testsuite. I'm now seeing lots of FAILs due to: ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. ...which Paolo mentioned in the other thread that he is hitting this too. There was some discussion on what to do, but has there been a decision on how to fix this yet? Or is it fixed upstream and we just need to merge that fix too? Peter ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-31 19:53 ` Peter Bergner @ 2014-06-02 4:54 ` Konstantin Serebryany 2014-06-02 5:57 ` Yury Gribov 0 siblings, 1 reply; 25+ messages in thread From: Konstantin Serebryany @ 2014-06-02 4:54 UTC (permalink / raw) To: Peter Bergner, Yuri Gribov Cc: Jakub Jelinek, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Sat, May 31, 2014 at 11:53 PM, Peter Bergner <bergner@vnet.ibm.com> wrote: > On Fri, 2014-05-30 at 15:49 +0200, Jakub Jelinek wrote: >> On Fri, May 30, 2014 at 08:09:22AM -0500, Peter Bergner wrote: >> > On Thu, 2014-05-29 at 14:07 -0500, Peter Bergner wrote: >> > > On Wed, 2014-05-28 at 09:36 +0200, Thomas Schwinge wrote: >> > > > This is being discussed in the thread at >> > > > <http://gcc.gnu.org/ml/gcc-patches/2014-05/msg02031.html>. Until that >> > > > has been resolved, I do agree to check in the following patch (and have >> > > > successfully tested it, but cannot formally approve it for commit; thus >> > > > copying the libsanitizer maintainers): >> > > >> > > The re-enablement patch was submitted to the llvm mailing list here: >> > > >> > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140526/219249.html >> > > >> > > Once that is committed and merged into gcc, we can re-enable building >> > > libsanitizer for powerpc*-linux. >> > >> > Ok, it was committed upstream as revision 209879. Kostya, can we get >> > this merged into gcc trunk and powerpc*-linux re-enabled again? Thanks. >> >> I've cherry-picked the two upstream commits and after testing on >> x86_64-linux/i686-linux committed to trunk. > > Great, thanks! I bootstrapped and ran the asan testsuite. I'm now seeing > lots of FAILs due to: > > ASan runtime does not come first in initial library list; you should either > link runtime to your application or manually preload it with LD_PRELOAD. > > ...which Paolo mentioned in the other thread that he is hitting this too. > There was some discussion on what to do, but has there been a decision on > how to fix this yet? Or is it fixed upstream and we just need to merge > that fix too? Yuri needs to send the patch to llvm-commits. > > Peter > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 4:54 ` Konstantin Serebryany @ 2014-06-02 5:57 ` Yury Gribov 2014-06-02 10:48 ` Konstantin Serebryany 0 siblings, 1 reply; 25+ messages in thread From: Yury Gribov @ 2014-06-02 5:57 UTC (permalink / raw) To: Konstantin Serebryany, Peter Bergner, Yuri Gribov Cc: Jakub Jelinek, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini >> There was some discussion on what to do, but has there been a decision on >> how to fix this yet? Or is it fixed upstream and we just need to merge >> that fix too? > Yuri needs to send the patch to llvm-commits. I think I already did that: D3911 -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 5:57 ` Yury Gribov @ 2014-06-02 10:48 ` Konstantin Serebryany 2014-06-03 4:42 ` Peter Bergner 0 siblings, 1 reply; 25+ messages in thread From: Konstantin Serebryany @ 2014-06-02 10:48 UTC (permalink / raw) To: Yury Gribov Cc: Peter Bergner, Yuri Gribov, Jakub Jelinek, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini Committed as r210012, please don't forget to add llvm-commits to CC next time (I did not see the message) Thanks! On Mon, Jun 2, 2014 at 9:57 AM, Yury Gribov <y.gribov@samsung.com> wrote: >>> There was some discussion on what to do, but has there been a decision on >>> how to fix this yet? Or is it fixed upstream and we just need to merge >>> that fix too? >> >> Yuri needs to send the patch to llvm-commits. > > > I think I already did that: D3911 > > -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 10:48 ` Konstantin Serebryany @ 2014-06-03 4:42 ` Peter Bergner 2014-06-03 6:19 ` Yury Gribov 0 siblings, 1 reply; 25+ messages in thread From: Peter Bergner @ 2014-06-03 4:42 UTC (permalink / raw) To: Konstantin Serebryany Cc: Yury Gribov, Yuri Gribov, Jakub Jelinek, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Mon, 2014-06-02 at 14:48 +0400, Konstantin Serebryany wrote: > Committed as r210012, please don't forget to add llvm-commits to CC > next time (I did not see the message) > Thanks! I took that patch and applied it to the gcc sources, but I still see the error on ppc: [bergner@makalu-lp1 asan]$ /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/ /home/bergner/gcc/gcc-fsf-mainline-asan/gcc/testsuite/c-c++-common/asan/asan-interface-1.c -B/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/ -B/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/ -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs -fsanitize=address -g -I/home/bergner/gcc/gcc-fsf-mainline-asan/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -lm -m32 -o ./asan-interface-1.exe [bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ./asan-interface-1.exe ==36082==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. [bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ldd ./asan-interface-1.exe linux-vdso32.so.1 => (0x00100000) libm.so.6 => /lib/power8/libm.so.6 (0x0ff00000) libasan.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so.1 (0x0f930000) libc.so.6 => /lib/power8/libc.so.6 (0x0f740000) /lib/ld.so.1 (0x206b0000) libpthread.so.0 => /lib/power8/libpthread.so.0 (0x0f6f0000) libdl.so.2 => /lib/libdl.so.2 (0x0f6b0000) libstdc++.so.6 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libstdc++-v3/src/.libs/libstdc++.so.6 (0x0f520000) libgcc_s.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32/libgcc_s.so.1 (0x0f4c0000) If I explicitly add a -lasan before the -lm on the compile, then everything works fine. Is this a test case error for not linking -lasan before -lm or ??? Peter ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 4:42 ` Peter Bergner @ 2014-06-03 6:19 ` Yury Gribov 2014-06-03 6:41 ` Jakub Jelinek 0 siblings, 1 reply; 25+ messages in thread From: Yury Gribov @ 2014-06-03 6:19 UTC (permalink / raw) To: Peter Bergner, Konstantin Serebryany Cc: Yuri Gribov, Jakub Jelinek, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini > I took that patch and applied it to the gcc sources, > but I still see the error on ppc: >... > [bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ldd ./asan-interface-1.exe > linux-vdso32.so.1 => (0x00100000) > libm.so.6 => /lib/power8/libm.so.6 (0x0ff00000) > libasan.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so.1 (0x0f930000) Now check indeed seems to be useful: libasan should be the first library in the list when -fsanitize=address flag is present. Are compiler specs for Power somehow special? -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 6:19 ` Yury Gribov @ 2014-06-03 6:41 ` Jakub Jelinek 2014-06-03 13:06 ` Peter Bergner 0 siblings, 1 reply; 25+ messages in thread From: Jakub Jelinek @ 2014-06-03 6:41 UTC (permalink / raw) To: Yury Gribov Cc: Peter Bergner, Konstantin Serebryany, Yuri Gribov, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote: > >I took that patch and applied it to the gcc sources, > >but I still see the error on ppc: > >... > >[bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ldd ./asan-interface-1.exe > > linux-vdso32.so.1 => (0x00100000) > > libm.so.6 => /lib/power8/libm.so.6 (0x0ff00000) > > libasan.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so.1 (0x0f930000) > > Now check indeed seems to be useful: libasan should be the first > library in the list when -fsanitize=address flag is present. Are > compiler specs for Power somehow special? -fsanitize=address should insert -lasan quite early on the linker command line, please try to cut'n'paste the command line from testsuite/g++/g++.log and add -v to see what is passed to the linker. Perhaps the linker reorders the libraries? Or do you have LD_PRELOAD? Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 6:41 ` Jakub Jelinek @ 2014-06-03 13:06 ` Peter Bergner 2014-06-03 13:17 ` Yury Gribov 2014-06-03 13:21 ` Jakub Jelinek 0 siblings, 2 replies; 25+ messages in thread From: Peter Bergner @ 2014-06-03 13:06 UTC (permalink / raw) To: Jakub Jelinek Cc: Yury Gribov, Konstantin Serebryany, Yuri Gribov, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Tue, 2014-06-03 at 08:41 +0200, Jakub Jelinek wrote: > On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote: > > >I took that patch and applied it to the gcc sources, > > >but I still see the error on ppc: > > >... > > >[bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ldd ./asan-interface-1.exe > > > linux-vdso32.so.1 => (0x00100000) > > > libm.so.6 => /lib/power8/libm.so.6 (0x0ff00000) > > > libasan.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so.1 (0x0f930000) > > > > Now check indeed seems to be useful: libasan should be the first > > library in the list when -fsanitize=address flag is present. Are > > compiler specs for Power somehow special? > > -fsanitize=address should insert -lasan quite early on the linker command > line, please try to cut'n'paste the command line from testsuite/g++/g++.log > and add -v to see what is passed to the linker. > Perhaps the linker reorders the libraries? > Or do you have LD_PRELOAD? No LD_PRELOAD. It adds -lasan "early", but after the libraries and object files that are explicitly added to the linker command. Since -lm is explicitly added to the linker command, the implicitly added -lasan comes after. The -v command is below. Peter /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/collect2 -plugin /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/liblto_plugin.so -plugin-opt=/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/lto-wrapper -plugin-opt=-fresolution=/tmp/cckyoSrJ.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -V -m elf32ppclinux -dynamic-linker /lib/ld.so.1 -o ./asan-interface-1.exe /lib/../lib/crt1.o /lib/../lib/crti.o /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32/crtbegin.o -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32 -L/lib/../lib -L/usr/lib/../lib -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer -L/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan /tmp/ccUTAlke.o -lm -lasan -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32/crtend.o /lib/../lib/crtn.o ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 13:06 ` Peter Bergner @ 2014-06-03 13:17 ` Yury Gribov 2014-06-03 13:21 ` Jakub Jelinek 1 sibling, 0 replies; 25+ messages in thread From: Yury Gribov @ 2014-06-03 13:17 UTC (permalink / raw) To: Peter Bergner, Jakub Jelinek Cc: Konstantin Serebryany, Yuri Gribov, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini > It adds -lasan "early", but after the libraries and > object files that are explicitly added to the linker command. > Since -lm is explicitly added to the linker command, the implicitly > added -lasan comes after. The -v command is below. Hm, -lasan manages to override user-specified -lm on gcc trunk for x64: $ /tmp/gcc-bootstrap-and-regtest/build-orig/gcc/xgcc -B/tmp/gcc-bootstrap-and-regtest/build-orig/gcc/ /home/ygribov/src/gcc-master/gcc/testsuite/c-c++-common/asan/asan-interface-1.c -B/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/ -B/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/asan/ -L/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs -fsanitize=address -g -I/home/ygribov/src/gcc-master/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -lm -o ./asan-interface-1.exe -v ... /tmp/gcc-bootstrap-and-regtest/build-orig/gcc/collect2 -plugin /tmp/gcc-bootstrap-and-regtest/build-orig/gcc/liblto_plugin.so -plugin-opt=/tmp/gcc-bootstrap-and-regtest/build-orig/gcc/lto-wrapper -plugin-opt=-fresolution=/tmp/ccZD4gPg.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o ./asan-interface-1.exe /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o /tmp/gcc-bootstrap-and-regtest/build-orig/gcc/crtbegin.o -L/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/asan/.libs -L/tmp/gcc-bootstrap-and-regtest/build-orig/gcc -L/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer -L/tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/asan -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu /tmp/gcc-bootstrap-and-regtest/build-orig/x86_64-unknown-linux-gnu/./libsanitizer/asan/libasan_preinit.o -lasan /tmp/ccgt1Kd9.o -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /tmp/gcc-bootstrap-and-regtest/build-orig/gcc/crtend.o /usr/lib/x86_64-linux-gnu/crtn.o -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 13:06 ` Peter Bergner 2014-06-03 13:17 ` Yury Gribov @ 2014-06-03 13:21 ` Jakub Jelinek 2014-06-03 13:39 ` Peter Bergner 1 sibling, 1 reply; 25+ messages in thread From: Jakub Jelinek @ 2014-06-03 13:21 UTC (permalink / raw) To: Peter Bergner Cc: Yury Gribov, Konstantin Serebryany, Yuri Gribov, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Tue, Jun 03, 2014 at 08:06:41AM -0500, Peter Bergner wrote: > On Tue, 2014-06-03 at 08:41 +0200, Jakub Jelinek wrote: > > On Tue, Jun 03, 2014 at 10:19:48AM +0400, Yury Gribov wrote: > > > >I took that patch and applied it to the gcc sources, > > > >but I still see the error on ppc: > > > >... > > > >[bergner@makalu-lp1 asan]$ LD_LIBRARY_PATH=:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs::/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/gcc/32:/home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs: ldd ./asan-interface-1.exe > > > > linux-vdso32.so.1 => (0x00100000) > > > > libm.so.6 => /lib/power8/libm.so.6 (0x0ff00000) > > > > libasan.so.1 => /home/bergner/gcc/build/gcc-fsf-mainline-asan-debug-3/powerpc64-linux/32/libsanitizer/asan/.libs/libasan.so.1 (0x0f930000) > > > > > > Now check indeed seems to be useful: libasan should be the first > > > library in the list when -fsanitize=address flag is present. Are > > > compiler specs for Power somehow special? > > > > -fsanitize=address should insert -lasan quite early on the linker command > > line, please try to cut'n'paste the command line from testsuite/g++/g++.log > > and add -v to see what is passed to the linker. > > Perhaps the linker reorders the libraries? > > Or do you have LD_PRELOAD? > > No LD_PRELOAD. It adds -lasan "early", but after the libraries and > object files that are explicitly added to the linker command. > Since -lm is explicitly added to the linker command, the implicitly > added -lasan comes after. The -v command is below. Ah, that is a powerpc*-linux* bug. All other linux targets include config/gnu-user.h header, perhaps early and override it, but rs6000* seems to be the only? exception that does not. So, either you need to include that header and perhaps tweak afterwards, or duplicate the asan/tsan related stuff in there and make sure to keep it up to date. Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-03 13:21 ` Jakub Jelinek @ 2014-06-03 13:39 ` Peter Bergner 0 siblings, 0 replies; 25+ messages in thread From: Peter Bergner @ 2014-06-03 13:39 UTC (permalink / raw) To: Jakub Jelinek Cc: Yury Gribov, Konstantin Serebryany, Yuri Gribov, Thomas Schwinge, Arseny Solokha, Dodji Seketeli, Kostya Serebryany, Dmitry Vyukov, GCC Patches, Paolo Carlini On Tue, 2014-06-03 at 15:21 +0200, Jakub Jelinek wrote: > On Tue, Jun 03, 2014 at 08:06:41AM -0500, Peter Bergner wrote: > > No LD_PRELOAD. It adds -lasan "early", but after the libraries and > > object files that are explicitly added to the linker command. > > Since -lm is explicitly added to the linker command, the implicitly > > added -lasan comes after. The -v command is below. > > Ah, that is a powerpc*-linux* bug. All other linux targets include > config/gnu-user.h header, perhaps early and override it, but rs6000* > seems to be the only? exception that does not. > > So, either you need to include that header and perhaps tweak afterwards, > or duplicate the asan/tsan related stuff in there and make sure to keep it > up to date. I'll try adding the include. Thanks for pointing that out! Peter ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-05-30 13:49 ` Jakub Jelinek 2014-05-30 18:02 ` Konstantin Serebryany 2014-05-31 19:53 ` Peter Bergner @ 2014-06-02 6:22 ` Yury Gribov 2014-06-02 7:56 ` Jakub Jelinek 2 siblings, 1 reply; 25+ messages in thread From: Yury Gribov @ 2014-06-02 6:22 UTC (permalink / raw) To: Jakub Jelinek, Peter Bergner Cc: Thomas Schwinge, Arseny Solokha, dodji, kcc, dvyukov, gcc-patches Looks like now function does not return anything for ARM case? I'd say we should replace this pc = ... with return like all other cases, the code is just asking for trouble. --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209878) +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209879) @@ -18,11 +18,13 @@ namespace __sanitizer { uptr StackTrace::GetPreviousInstructionPc(uptr pc) { -#ifdef __arm__ +#if defined(__arm__) // Cancel Thumb bit. pc = pc & (~1); -#endif -#if defined(__sparc__) +#elif defined(__powerpc__) || defined(__powerpc64__) + // PCs are always 4 byte aligned. + return pc - 4; +#elif defined(__sparc__) return pc - 8; #else return pc - 1; ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 6:22 ` Yury Gribov @ 2014-06-02 7:56 ` Jakub Jelinek 2014-06-02 8:40 ` Yury Gribov 2014-06-02 9:24 ` Ramana Radhakrishnan 0 siblings, 2 replies; 25+ messages in thread From: Jakub Jelinek @ 2014-06-02 7:56 UTC (permalink / raw) To: Yury Gribov Cc: Peter Bergner, Thomas Schwinge, Arseny Solokha, dodji, kcc, dvyukov, gcc-patches On Mon, Jun 02, 2014 at 10:22:11AM +0400, Yury Gribov wrote: > Looks like now function does not return anything for ARM case? I'd > say we should replace this pc = ... with return like all other > cases, the code is just asking for trouble. But it should be return (pc & ~(uptr)1) - 1; right? > --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209878) > +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209879) > @@ -18,11 +18,13 @@ > namespace __sanitizer { > > uptr StackTrace::GetPreviousInstructionPc(uptr pc) { > -#ifdef __arm__ > +#if defined(__arm__) > // Cancel Thumb bit. > pc = pc & (~1); > -#endif > -#if defined(__sparc__) > +#elif defined(__powerpc__) || defined(__powerpc64__) > + // PCs are always 4 byte aligned. > + return pc - 4; > +#elif defined(__sparc__) > return pc - 8; > #else > return pc - 1; Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 7:56 ` Jakub Jelinek @ 2014-06-02 8:40 ` Yury Gribov 2014-06-02 9:24 ` Ramana Radhakrishnan 1 sibling, 0 replies; 25+ messages in thread From: Yury Gribov @ 2014-06-02 8:40 UTC (permalink / raw) To: Jakub Jelinek Cc: Peter Bergner, Thomas Schwinge, Arseny Solokha, dodji, kcc, dvyukov, gcc-patches On 06/02/2014 11:56 AM, Jakub Jelinek wrote: >> Looks like now function does not return anything for ARM case? I'd >> say we should replace this pc = ... with return like all other >> cases, the code is just asking for trouble. > > But it should be > return (pc & ~(uptr)1) - 1; > right? Yes, I had something like this in mind. -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 7:56 ` Jakub Jelinek 2014-06-02 8:40 ` Yury Gribov @ 2014-06-02 9:24 ` Ramana Radhakrishnan 2014-06-02 9:28 ` Jakub Jelinek 1 sibling, 1 reply; 25+ messages in thread From: Ramana Radhakrishnan @ 2014-06-02 9:24 UTC (permalink / raw) To: Jakub Jelinek Cc: Yury Gribov, Peter Bergner, Thomas Schwinge, Arseny Solokha, DodjiSeketeli, kcc, Dmitry Vyukov, gcc-patches On Mon, Jun 2, 2014 at 8:56 AM, Jakub Jelinek <jakub@redhat.com> wrote: > On Mon, Jun 02, 2014 at 10:22:11AM +0400, Yury Gribov wrote: >> Looks like now function does not return anything for ARM case? I'd >> say we should replace this pc = ... with return like all other >> cases, the code is just asking for trouble. > > But it should be > return (pc & ~(uptr)1) - 1; Why the -1 ? No ARM or Thumb instruction is 1 byte long. Instructions are 4 bytes long if in ARM state and could be 2 or 4 bytes if Thumb state. regards Ramana > right? > >> --- libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209878) >> +++ libsanitizer/sanitizer_common/sanitizer_stacktrace.cc (revision 209879) >> @@ -18,11 +18,13 @@ >> namespace __sanitizer { >> >> uptr StackTrace::GetPreviousInstructionPc(uptr pc) { >> -#ifdef __arm__ >> +#if defined(__arm__) >> // Cancel Thumb bit. >> pc = pc & (~1); >> -#endif >> -#if defined(__sparc__) >> +#elif defined(__powerpc__) || defined(__powerpc64__) >> + // PCs are always 4 byte aligned. >> + return pc - 4; >> +#elif defined(__sparc__) >> return pc - 8; >> #else >> return pc - 1; > > Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 9:24 ` Ramana Radhakrishnan @ 2014-06-02 9:28 ` Jakub Jelinek 2014-06-02 9:44 ` Yury Gribov 0 siblings, 1 reply; 25+ messages in thread From: Jakub Jelinek @ 2014-06-02 9:28 UTC (permalink / raw) To: ramrad01 Cc: Yury Gribov, Peter Bergner, Thomas Schwinge, Arseny Solokha, DodjiSeketeli, kcc, Dmitry Vyukov, gcc-patches On Mon, Jun 02, 2014 at 10:24:32AM +0100, Ramana Radhakrishnan wrote: > On Mon, Jun 2, 2014 at 8:56 AM, Jakub Jelinek <jakub@redhat.com> wrote: > > On Mon, Jun 02, 2014 at 10:22:11AM +0400, Yury Gribov wrote: > >> Looks like now function does not return anything for ARM case? I'd > >> say we should replace this pc = ... with return like all other > >> cases, the code is just asking for trouble. > > > > But it should be > > return (pc & ~(uptr)1) - 1; > > Why the -1 ? No ARM or Thumb instruction is 1 byte long. Instructions > are 4 bytes long if in ARM state and could be 2 or 4 bytes if Thumb > state. Well, that is what the code did before this patch. The -1 just points to the middle of previous instruction, so that supposedly it can be looked up in debug info etc. Now, if all insns are at least 2 bytes long, perhaps you could subtract 2. Jakub ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 9:28 ` Jakub Jelinek @ 2014-06-02 9:44 ` Yury Gribov 2014-06-02 10:04 ` Ramana Radhakrishnan 0 siblings, 1 reply; 25+ messages in thread From: Yury Gribov @ 2014-06-02 9:44 UTC (permalink / raw) To: Jakub Jelinek, ramrad01 Cc: Peter Bergner, Thomas Schwinge, Arseny Solokha, DodjiSeketeli, kcc, Dmitry Vyukov, gcc-patches >> Why the -1 ? No ARM or Thumb instruction is 1 byte long. Instructions >> are 4 bytes long if in ARM state and could be 2 or 4 bytes if Thumb >> state. > > The -1 just points to the middle of previous instruction, > so that supposedly it can be looked up in debug info etc. Right, that works quite well with gdb, addr2line, etc. I once tried adding proper handling of ARM/Thumb but this complicated code with no real benefit. -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH] Do not build libsanitizer also for powerpc*-*-linux* 2014-06-02 9:44 ` Yury Gribov @ 2014-06-02 10:04 ` Ramana Radhakrishnan 0 siblings, 0 replies; 25+ messages in thread From: Ramana Radhakrishnan @ 2014-06-02 10:04 UTC (permalink / raw) To: Yury Gribov Cc: Jakub Jelinek, Peter Bergner, Thomas Schwinge, Arseny Solokha, DodjiSeketeli, kcc, Dmitry Vyukov, gcc-patches On Mon, Jun 2, 2014 at 10:44 AM, Yury Gribov <y.gribov@samsung.com> wrote: >>> Why the -1 ? No ARM or Thumb instruction is 1 byte long. Instructions >>> are 4 bytes long if in ARM state and could be 2 or 4 bytes if Thumb >>> state. >> >> >> The -1 just points to the middle of previous instruction, >> so that supposedly it can be looked up in debug info etc. > > > Right, that works quite well with gdb, addr2line, etc. I once tried adding > proper handling of ARM/Thumb but this complicated code with no real benefit. Well, then put a comment in . A casual reader will have the same reaction that I just did. Ramana > > -Y ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2014-06-03 13:39 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <1401100995.27542.ezmlm@gcc.gnu.org> 2014-05-26 10:53 ` [PATCH] Do not build libsanitizer also for powerpc*-*-linux* Arseny Solokha 2014-05-26 11:29 ` Konstantin Serebryany 2014-05-28 7:36 ` Thomas Schwinge 2014-05-29 19:08 ` Peter Bergner 2014-05-30 13:09 ` Peter Bergner 2014-05-30 13:49 ` Jakub Jelinek 2014-05-30 18:02 ` Konstantin Serebryany 2014-05-31 19:53 ` Peter Bergner 2014-06-02 4:54 ` Konstantin Serebryany 2014-06-02 5:57 ` Yury Gribov 2014-06-02 10:48 ` Konstantin Serebryany 2014-06-03 4:42 ` Peter Bergner 2014-06-03 6:19 ` Yury Gribov 2014-06-03 6:41 ` Jakub Jelinek 2014-06-03 13:06 ` Peter Bergner 2014-06-03 13:17 ` Yury Gribov 2014-06-03 13:21 ` Jakub Jelinek 2014-06-03 13:39 ` Peter Bergner 2014-06-02 6:22 ` Yury Gribov 2014-06-02 7:56 ` Jakub Jelinek 2014-06-02 8:40 ` Yury Gribov 2014-06-02 9:24 ` Ramana Radhakrishnan 2014-06-02 9:28 ` Jakub Jelinek 2014-06-02 9:44 ` Yury Gribov 2014-06-02 10:04 ` Ramana Radhakrishnan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).