maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/compiler-rt/lib/tsan/rtl/tsan_platform.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

989 lines
37 KiB
C
Raw Normal View History

[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
//===-- tsan_platform.h -----------------------------------------*- C++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file is a part of ThreadSanitizer (TSan), a race detector.
//
// Platform-specific code.
//===----------------------------------------------------------------------===//
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
#ifndef TSAN_PLATFORM_H
#define TSAN_PLATFORM_H
#if !defined(__LP64__) && !defined(_WIN64)
# error "Only 64-bit is supported"
#endif
#include "tsan_defs.h"
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
#include "tsan_trace.h"
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
namespace __tsan {
tsan: unit-test all mappings Move the mapping checking logic from startup to unit tests and test all mapping instead of just the active one. This makes it much more feasible to make any global changes to the mappings since we have 17 of them. Depends on D107740. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107741
2021-08-07 19:07:00 +08:00
enum {
// App memory is not mapped onto shadow memory range.
kBrokenMapping = 1 << 0,
// Mapping app memory and back does not produce the same address,
// this can lead to wrong addresses in reports and potentially
// other bad consequences.
kBrokenReverseMapping = 1 << 1,
// Mapping is non-linear for linear user range.
// This is bad and can lead to unpredictable memory corruptions, etc
// because range access functions assume linearity.
kBrokenLinearity = 1 << 2,
};
tsan: add description of memory layouts in different configs llvm-svn: 168777
2012-11-28 15:44:26 +08:00
/*
[TSan][MIPS] Adding support for MIPS64 Patch by Sagar Thakur Reviewers: dvyukov, samsonov, petarj, kcc, dsanders. Subscribers: mohit.bhakkad, Anand.Takale, llvm-commits. Differential Revision: http://reviews.llvm.org/D6291 llvm-svn: 229972
2015-02-20 14:42:41 +08:00
C/C++ on linux/x86_64 and freebsd/x86_64
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
0000 0000 1000 - 0080 0000 0000: main binary and/or MAP_32BIT mappings (512GB)
tsan: support pie binaries on newer kernels 4.1+ Linux kernels map pie binaries at 0x55: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90 Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503). Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb). This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb. This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping. llvm-svn: 282152
2016-09-22 21:42:02 +08:00
0040 0000 0000 - 0100 0000 0000: -
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
0100 0000 0000 - 2000 0000 0000: shadow
2000 0000 0000 - 3000 0000 0000: -
tsan: refactor storage of meta information for heap blocks and sync objects The new storage (MetaMap) is based on direct shadow (instead of a hashmap + per-block lists). This solves a number of problems: - eliminates quadratic behaviour in SyncTab::GetAndLock (https://code.google.com/p/thread-sanitizer/issues/detail?id=26) - eliminates contention in SyncTab - eliminates contention in internal allocator during allocation of sync objects - removes a bunch of ad-hoc code in java interface - reduces java shadow from 2x to 1/2x - allows to memorize heap block meta info for Java and Go - allows to cleanup sync object meta info for Go - which in turn enabled deadlock detector for Go llvm-svn: 209810
2014-05-29 21:50:54 +08:00
3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects)
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
4000 0000 0000 - 5500 0000 0000: -
5500 0000 0000 - 5680 0000 0000: pie binaries without ASLR or on 4.1+ kernels
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
5680 0000 0000 - 6000 0000 0000: -
6000 0000 0000 - 6200 0000 0000: traces
6200 0000 0000 - 7d00 0000 0000: -
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
7b00 0000 0000 - 7c00 0000 0000: heap
7c00 0000 0000 - 7e80 0000 0000: -
7e80 0000 0000 - 8000 0000 0000: modules and main thread stack
Add NetBSD improvements in sanitizers Summary: Changes: * Add initial msan stub support. * Handle NetBSD specific pthread_setname_np(3). * NetBSD supports __attribute__((tls_model("initial-exec"))), define it in SANITIZER_TLS_INITIAL_EXEC_ATTRIBUTE. * Add ReExec() specific bits for NetBSD. * Simplify code and add syscall64 and syscall_ptr for !NetBSD. * Correct bunch of syscall wrappers for NetBSD. * Disable test/tsan/map32bit on NetBSD as not applicable. * Port test/tsan/strerror_r to a POSIX-compliant OSes. * Disable __libc_stack_end on NetBSD. * Disable ReadNullSepFileToArray() on NetBSD. * Define struct_ElfW_Phdr_sz, detected missing symbol by msan. * Change type of __sanitizer_FILE from void to char. This helps to reuse this type as an array. Long term it will be properly implemented along with SANITIZER_HAS_STRUCT_FILE setting to 1. * Add initial NetBSD support in lib/tsan/go/buildgo.sh. * Correct referencing stdout and stderr in tsan_interceptors.cc on NetBSD. * Document NetBSD x86_64 specific virtual memory layout in tsan_platform.h. * Port tests/rtl/tsan_test_util_posix.cc to NetBSD. * Enable NetBSD tests in test/msan/lit.cfg. * Enable NetBSD tests in test/tsan/lit.cfg. Sponsored by <The NetBSD Foundation> Reviewers: joerg, vitalybuka, eugenis, kcc, dvyukov Reviewed By: dvyukov Subscribers: #sanitizers, llvm-commits, kubamracek Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D39124 llvm-svn: 316591
2017-10-26 01:09:05 +08:00
C/C++ on netbsd/amd64 can reuse the same mapping:
* The address space starts from 0x1000 (option with 0x0) and ends with
0x7f7ffffff000.
* LoAppMem-kHeapMemEnd can be reused as it is.
* No VDSO support.
* No MidAppMem region.
* No additional HeapMem region.
* HiAppMem contains the stack, loader, shared libraries and heap.
* Stack on NetBSD/amd64 has prereserved 128MB.
* Heap grows downwards (top-down).
* ASLR must be disabled per-process or globally.
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct Mapping48AddressSpace {
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kMetaShadowBeg = 0x300000000000ull;
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
static const uptr kMetaShadowEnd = 0x340000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x600000000000ull;
static const uptr kTraceMemEnd = 0x620000000000ull;
tsan: support pie binaries on newer kernels 4.1+ Linux kernels map pie binaries at 0x55: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90 Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503). Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb). This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb. This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping. llvm-svn: 282152
2016-09-22 21:42:02 +08:00
static const uptr kShadowBeg = 0x010000000000ull;
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
static const uptr kShadowEnd = 0x200000000000ull;
static const uptr kHeapMemBeg = 0x7b0000000000ull;
static const uptr kHeapMemEnd = 0x7c0000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
static const uptr kLoAppMemEnd = 0x008000000000ull;
static const uptr kMidAppMemBeg = 0x550000000000ull;
tsan: support pie binaries on newer kernels 4.1+ Linux kernels map pie binaries at 0x55: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90 Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503). Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb). This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb. This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping. llvm-svn: 282152
2016-09-22 21:42:02 +08:00
static const uptr kMidAppMemEnd = 0x568000000000ull;
tsan: make shadow mapping linear within a single user region This is a follow up to r282152. A more extensive testing on real apps revealed a subtle bug in r282152. The revision made shadow mapping non-linear even within a single user region. But there are lots of code in runtime that processes memory ranges and assumes that mapping is linear. For example, region memory access handling simply increments shadow address to advance to the next shadow cell group. Similarly, DontNeedShadowFor, java memory mover, search of heap memory block header, etc make similar assumptions. To trigger the bug user range would need to cross 0x008000000000 boundary. This was observed for a module data section. Make shadow mapping linear within a single user range again. Add a startup CHECK for linearity. llvm-svn: 282405
2016-09-26 21:41:33 +08:00
static const uptr kHiAppMemBeg = 0x7e8000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHiAppMemEnd = 0x800000000000ull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x780000000000ull;
static const uptr kShadowXor = 0x040000000000ull;
static const uptr kShadowAdd = 0x000000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kVdsoBeg = 0xf000000000000000ull;
};
tsan: support pie binaries on newer kernels 4.1+ Linux kernels map pie binaries at 0x55: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d1fd836dcf00d2028c700c7e44d2c23404062c90 Currently tsan does not support app memory at 0x55 (https://github.com/google/sanitizers/issues/503). Older kernels also map pie binaries at 0x55 when ASLR is disables (most notably under gdb). This change extends tsan mapping for linux/x86_64 to cover 0x554-0x568 app range and fixes both 4.1+ kernels and gdb. This required to slightly shrink low and high app ranges and move heap. The mapping become even more non-linear, since now we xor lower bits. Now even a continuous app range maps to split, intermixed shadow ranges. This breaks ShadowToMemImpl as it assumes linear mapping at least within a continuous app range (however it turned out to be already broken at least on arm64/42-bit vma as uncovered by r281970). So also change ShadowToMemImpl to hopefully a more robust implementation that does not assume a linear mapping. llvm-svn: 282152
2016-09-22 21:42:02 +08:00
[TSan][MIPS] Adding support for MIPS64 Patch by Sagar Thakur Reviewers: dvyukov, samsonov, petarj, kcc, dsanders. Subscribers: mohit.bhakkad, Anand.Takale, llvm-commits. Differential Revision: http://reviews.llvm.org/D6291 llvm-svn: 229972
2015-02-20 14:42:41 +08:00
/*
[TSan][MIPS] Expand sanitizer memory space to lower addresses MemToShadowImpl() maps lower addresses to a memory space out of sanitizers range. The simplest example is address 0 which is mapped to 0x2000000000 static const uptr kShadowBeg = 0x2400000000ull; but accessing the address during tsan execution will lead to a segmentation fault. This patch expands the range used by the sanitizer and ensures that 1/8 of the maximum valid address in the virtual address spaces is used for shadow memory. Patch by Milos Stojanovic. Differential Revision: https://reviews.llvm.org/D41777 llvm-svn: 323013
2018-01-20 08:06:07 +08:00
C/C++ on linux/mips64 (40-bit VMA)
0000 0000 00 - 0100 0000 00: - (4 GB)
0100 0000 00 - 0200 0000 00: main binary (4 GB)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0200 0000 00 - 2000 0000 00: - (120 GB)
2000 0000 00 - 4000 0000 00: shadow (128 GB)
[TSan][MIPS] Expand sanitizer memory space to lower addresses MemToShadowImpl() maps lower addresses to a memory space out of sanitizers range. The simplest example is address 0 which is mapped to 0x2000000000 static const uptr kShadowBeg = 0x2400000000ull; but accessing the address during tsan execution will lead to a segmentation fault. This patch expands the range used by the sanitizer and ensures that 1/8 of the maximum valid address in the virtual address spaces is used for shadow memory. Patch by Milos Stojanovic. Differential Revision: https://reviews.llvm.org/D41777 llvm-svn: 323013
2018-01-20 08:06:07 +08:00
4000 0000 00 - 5000 0000 00: metainfo (memory blocks and sync objects) (64 GB)
5000 0000 00 - aa00 0000 00: - (360 GB)
aa00 0000 00 - ab00 0000 00: main binary (PIE) (4 GB)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
ab00 0000 00 - b000 0000 00: - (20 GB)
b000 0000 00 - b200 0000 00: traces (8 GB)
b200 0000 00 - fe00 0000 00: - (304 GB)
[TSan][MIPS] Expand sanitizer memory space to lower addresses MemToShadowImpl() maps lower addresses to a memory space out of sanitizers range. The simplest example is address 0 which is mapped to 0x2000000000 static const uptr kShadowBeg = 0x2400000000ull; but accessing the address during tsan execution will lead to a segmentation fault. This patch expands the range used by the sanitizer and ensures that 1/8 of the maximum valid address in the virtual address spaces is used for shadow memory. Patch by Milos Stojanovic. Differential Revision: https://reviews.llvm.org/D41777 llvm-svn: 323013
2018-01-20 08:06:07 +08:00
fe00 0000 00 - ff00 0000 00: heap (4 GB)
ff00 0000 00 - ff80 0000 00: - (2 GB)
ff80 0000 00 - ffff ffff ff: modules and main thread stack (<2 GB)
[TSan][MIPS] Adding support for MIPS64 Patch by Sagar Thakur Reviewers: dvyukov, samsonov, petarj, kcc, dsanders. Subscribers: mohit.bhakkad, Anand.Takale, llvm-commits. Differential Revision: http://reviews.llvm.org/D6291 llvm-svn: 229972
2015-02-20 14:42:41 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingMips64_40 {
[TSan][MIPS] Changes mips memory layout to support pie with address space randomization. Reviewed by dvyukov Differential: D23644 llvm-svn: 279505
2016-08-23 16:15:25 +08:00
static const uptr kMetaShadowBeg = 0x4000000000ull;
static const uptr kMetaShadowEnd = 0x5000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0xb000000000ull;
static const uptr kTraceMemEnd = 0xb200000000ull;
static const uptr kShadowBeg = 0x2000000000ull;
[TSan][MIPS] Changes mips memory layout to support pie with address space randomization. Reviewed by dvyukov Differential: D23644 llvm-svn: 279505
2016-08-23 16:15:25 +08:00
static const uptr kShadowEnd = 0x4000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHeapMemBeg = 0xfe00000000ull;
static const uptr kHeapMemEnd = 0xff00000000ull;
static const uptr kLoAppMemBeg = 0x0100000000ull;
static const uptr kLoAppMemEnd = 0x0200000000ull;
[TSan][MIPS] Changes mips memory layout to support pie with address space randomization. Reviewed by dvyukov Differential: D23644 llvm-svn: 279505
2016-08-23 16:15:25 +08:00
static const uptr kMidAppMemBeg = 0xaa00000000ull;
static const uptr kMidAppMemEnd = 0xab00000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHiAppMemBeg = 0xff80000000ull;
static const uptr kHiAppMemEnd = 0xffffffffffull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0xf800000000ull;
static const uptr kShadowXor = 0x0800000000ull;
static const uptr kShadowAdd = 0x0000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kVdsoBeg = 0xfffff00000ull;
};
[TSan][MIPS] Changes mips memory layout to support pie with address space randomization. Reviewed by dvyukov Differential: D23644 llvm-svn: 279505
2016-08-23 16:15:25 +08:00
[tsan] Add a mapping for Darwin/AArch64 This patch defines the TSan memory map and offsets for Darwin on AArch64. Differential Revision: https://reviews.llvm.org/D35147 llvm-svn: 307544
2017-07-10 23:35:04 +08:00
/*
C/C++ on Darwin/iOS/ARM64 (36-bit VMA, 64 GB VM)
0000 0000 00 - 0100 0000 00: - (4 GB)
0100 0000 00 - 0200 0000 00: main binary, modules, thread stacks (4 GB)
0200 0000 00 - 0300 0000 00: heap (4 GB)
0300 0000 00 - 0400 0000 00: - (4 GB)
0400 0000 00 - 0c00 0000 00: shadow memory (32 GB)
0c00 0000 00 - 0d00 0000 00: - (4 GB)
0d00 0000 00 - 0e00 0000 00: metainfo (4 GB)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0e00 0000 00 - 0f00 0000 00: - (4 GB)
0f00 0000 00 - 0fc0 0000 00: traces (3 GB)
0fc0 0000 00 - 1000 0000 00: -
[tsan] Add a mapping for Darwin/AArch64 This patch defines the TSan memory map and offsets for Darwin on AArch64. Differential Revision: https://reviews.llvm.org/D35147 llvm-svn: 307544
2017-07-10 23:35:04 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingAppleAarch64 {
[tsan] Add a mapping for Darwin/AArch64 This patch defines the TSan memory map and offsets for Darwin on AArch64. Differential Revision: https://reviews.llvm.org/D35147 llvm-svn: 307544
2017-07-10 23:35:04 +08:00
static const uptr kLoAppMemBeg = 0x0100000000ull;
static const uptr kLoAppMemEnd = 0x0200000000ull;
static const uptr kHeapMemBeg = 0x0200000000ull;
static const uptr kHeapMemEnd = 0x0300000000ull;
static const uptr kShadowBeg = 0x0400000000ull;
static const uptr kShadowEnd = 0x0c00000000ull;
static const uptr kMetaShadowBeg = 0x0d00000000ull;
static const uptr kMetaShadowEnd = 0x0e00000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x0f00000000ull;
static const uptr kTraceMemEnd = 0x0fc0000000ull;
Update TSan/ARM64 max VM to 0xfc0000000 to reflect a kernel change. llvm-svn: 318103
2017-11-14 07:04:47 +08:00
static const uptr kHiAppMemBeg = 0x0fc0000000ull;
static const uptr kHiAppMemEnd = 0x0fc0000000ull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x0ull;
static const uptr kShadowXor = 0x0ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kShadowAdd = 0x0ull;
[tsan] Add a mapping for Darwin/AArch64 This patch defines the TSan memory map and offsets for Darwin on AArch64. Differential Revision: https://reviews.llvm.org/D35147 llvm-svn: 307544
2017-07-10 23:35:04 +08:00
static const uptr kVdsoBeg = 0x7000000000000000ull;
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
[tsan] Add a mapping for Darwin/AArch64 This patch defines the TSan memory map and offsets for Darwin on AArch64. Differential Revision: https://reviews.llvm.org/D35147 llvm-svn: 307544
2017-07-10 23:35:04 +08:00
};
[tsan] Enable tsan for aarch64 This patch enabled TSAN for aarch64 with 39-bit VMA layout. As defined by tsan_platform.h the layout used is: 0000 4000 00 - 0200 0000 00: main binary 2000 0000 00 - 4000 0000 00: shadow memory 4000 0000 00 - 5000 0000 00: metainfo 5000 0000 00 - 6000 0000 00: - 6000 0000 00 - 6200 0000 00: traces 6200 0000 00 - 7d00 0000 00: - 7d00 0000 00 - 7e00 0000 00: heap 7e00 0000 00 - 7fff ffff ff: modules and main thread stack Which gives it about 8GB for main binary, 4GB for heap and 8GB for modules and main thread stack. Most of tests are passing, with the exception of: * ignore_lib0, ignore_lib1, ignore_lib3 due a kernel limitation for no support to make mmap page non-executable. * longjmp tests due missing specialized assembly routines. These tests are xfail for now. The only tsan issue still showing is: rtl/TsanRtlTest/Posix.ThreadLocalAccesses Which still required further investigation. The test is disable for aarch64 for now. llvm-svn: 244055
2015-08-05 23:17:59 +08:00
/*
C/C++ on linux/aarch64 (39-bit VMA)
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
0000 0010 00 - 0100 0000 00: main binary
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0100 0000 00 - 0800 0000 00: -
0800 0000 00 - 2000 0000 00: shadow memory
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
2000 0000 00 - 3100 0000 00: -
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
3100 0000 00 - 3400 0000 00: metainfo
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
3400 0000 00 - 5500 0000 00: -
5500 0000 00 - 5600 0000 00: main binary (PIE)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
5600 0000 00 - 6000 0000 00: -
6000 0000 00 - 6200 0000 00: traces
6200 0000 00 - 7d00 0000 00: -
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
7c00 0000 00 - 7d00 0000 00: heap
7d00 0000 00 - 7fff ffff ff: modules and main thread stack
[tsan] Enable tsan for aarch64 This patch enabled TSAN for aarch64 with 39-bit VMA layout. As defined by tsan_platform.h the layout used is: 0000 4000 00 - 0200 0000 00: main binary 2000 0000 00 - 4000 0000 00: shadow memory 4000 0000 00 - 5000 0000 00: metainfo 5000 0000 00 - 6000 0000 00: - 6000 0000 00 - 6200 0000 00: traces 6200 0000 00 - 7d00 0000 00: - 7d00 0000 00 - 7e00 0000 00: heap 7e00 0000 00 - 7fff ffff ff: modules and main thread stack Which gives it about 8GB for main binary, 4GB for heap and 8GB for modules and main thread stack. Most of tests are passing, with the exception of: * ignore_lib0, ignore_lib1, ignore_lib3 due a kernel limitation for no support to make mmap page non-executable. * longjmp tests due missing specialized assembly routines. These tests are xfail for now. The only tsan issue still showing is: rtl/TsanRtlTest/Posix.ThreadLocalAccesses Which still required further investigation. The test is disable for aarch64 for now. llvm-svn: 244055
2015-08-05 23:17:59 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingAarch64_39 {
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kLoAppMemBeg = 0x0000001000ull;
static const uptr kLoAppMemEnd = 0x0100000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kShadowBeg = 0x0800000000ull;
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
static const uptr kShadowEnd = 0x2000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kMetaShadowBeg = 0x3100000000ull;
static const uptr kMetaShadowEnd = 0x3400000000ull;
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
static const uptr kMidAppMemBeg = 0x5500000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kMidAppMemEnd = 0x5600000000ull;
static const uptr kTraceMemBeg = 0x6000000000ull;
static const uptr kTraceMemEnd = 0x6200000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHeapMemBeg = 0x7c00000000ull;
static const uptr kHeapMemEnd = 0x7d00000000ull;
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
static const uptr kHiAppMemBeg = 0x7e00000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHiAppMemEnd = 0x7fffffffffull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x7800000000ull;
static const uptr kShadowXor = 0x0200000000ull;
static const uptr kShadowAdd = 0x0000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kVdsoBeg = 0x7f00000000ull;
};
[compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMA This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). llvm-svn: 246330
2015-08-29 04:40:50 +08:00
/*
C/C++ on linux/aarch64 (42-bit VMA)
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
00000 0010 00 - 01000 0000 00: main binary
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
01000 0000 00 - 10000 0000 00: -
10000 0000 00 - 20000 0000 00: shadow memory
[compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMA This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). llvm-svn: 246330
2015-08-29 04:40:50 +08:00
20000 0000 00 - 26000 0000 00: -
26000 0000 00 - 28000 0000 00: metainfo
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
28000 0000 00 - 2aa00 0000 00: -
2aa00 0000 00 - 2ab00 0000 00: main binary (PIE)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
2ab00 0000 00 - 36200 0000 00: -
36200 0000 00 - 36240 0000 00: traces
36240 0000 00 - 3e000 0000 00: -
[compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMA This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). llvm-svn: 246330
2015-08-29 04:40:50 +08:00
3e000 0000 00 - 3f000 0000 00: heap
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
3f000 0000 00 - 3ffff ffff ff: modules and main thread stack
[compiler-rt] [tsan] Enable TSan for AArch64/42-bit VMA This patch adds support for tsan on aarch64-linux with 42-bit VMA (current default config for 64K pagesize kernels). The support is enabled by defining the SANITIZER_AARCH64_VMA to 42 at build time for both clang/llvm and compiler-rt. The default VMA is 39 bits. It also enabled tsan for previous supported VMA (39). llvm-svn: 246330
2015-08-29 04:40:50 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingAarch64_42 {
tsan: unit-test all mappings Move the mapping checking logic from startup to unit tests and test all mapping instead of just the active one. This makes it much more feasible to make any global changes to the mappings since we have 17 of them. Depends on D107740. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107741
2021-08-07 19:07:00 +08:00
static const uptr kBroken = kBrokenReverseMapping;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kLoAppMemBeg = 0x00000001000ull;
static const uptr kLoAppMemEnd = 0x01000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kShadowBeg = 0x10000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kShadowEnd = 0x20000000000ull;
static const uptr kMetaShadowBeg = 0x26000000000ull;
static const uptr kMetaShadowEnd = 0x28000000000ull;
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
static const uptr kMidAppMemBeg = 0x2aa00000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kMidAppMemEnd = 0x2ab00000000ull;
static const uptr kTraceMemBeg = 0x36200000000ull;
static const uptr kTraceMemEnd = 0x36400000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kHeapMemBeg = 0x3e000000000ull;
static const uptr kHeapMemEnd = 0x3f000000000ull;
static const uptr kHiAppMemBeg = 0x3f000000000ull;
static const uptr kHiAppMemEnd = 0x3ffffffffffull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x3c000000000ull;
static const uptr kShadowXor = 0x04000000000ull;
static const uptr kShadowAdd = 0x00000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kVdsoBeg = 0x37f00000000ull;
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
};
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingAarch64_48 {
tsan: Enable 48-bit VMA support on aarch64 This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
2016-07-29 20:45:35 +08:00
static const uptr kLoAppMemBeg = 0x0000000001000ull;
static const uptr kLoAppMemEnd = 0x0000200000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kShadowBeg = 0x0002000000000ull;
tsan: Enable 48-bit VMA support on aarch64 This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
2016-07-29 20:45:35 +08:00
static const uptr kShadowEnd = 0x0004000000000ull;
static const uptr kMetaShadowBeg = 0x0005000000000ull;
static const uptr kMetaShadowEnd = 0x0006000000000ull;
static const uptr kMidAppMemBeg = 0x0aaaa00000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kMidAppMemEnd = 0x0aaaf00000000ull;
static const uptr kTraceMemBeg = 0x0f06000000000ull;
static const uptr kTraceMemEnd = 0x0f06200000000ull;
tsan: Enable 48-bit VMA support on aarch64 This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
2016-07-29 20:45:35 +08:00
static const uptr kHeapMemBeg = 0x0ffff00000000ull;
static const uptr kHeapMemEnd = 0x0ffff00000000ull;
static const uptr kHiAppMemBeg = 0x0ffff00000000ull;
static const uptr kHiAppMemEnd = 0x1000000000000ull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x0fff800000000ull;
static const uptr kShadowXor = 0x0000800000000ull;
static const uptr kShadowAdd = 0x0000000000000ull;
tsan: Enable 48-bit VMA support on aarch64 This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
2016-07-29 20:45:35 +08:00
static const uptr kVdsoBeg = 0xffff000000000ull;
};
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
/*
C/C++ on linux/powerpc64 (44-bit VMA)
0000 0000 0100 - 0001 0000 0000: main binary
0001 0000 0000 - 0001 0000 0000: -
0001 0000 0000 - 0b00 0000 0000: shadow
0b00 0000 0000 - 0b00 0000 0000: -
0b00 0000 0000 - 0d00 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0d00 0000 0000 - 0d00 0000 0000: -
0d00 0000 0000 - 0f00 0000 0000: traces
0f00 0000 0000 - 0f00 0000 0000: -
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
0f00 0000 0000 - 0f50 0000 0000: heap
0f50 0000 0000 - 0f60 0000 0000: -
0f60 0000 0000 - 1000 0000 0000: modules and main thread stack
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingPPC64_44 {
tsan: unit-test all mappings Move the mapping checking logic from startup to unit tests and test all mapping instead of just the active one. This makes it much more feasible to make any global changes to the mappings since we have 17 of them. Depends on D107740. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107741
2021-08-07 19:07:00 +08:00
static const uptr kBroken =
kBrokenMapping | kBrokenReverseMapping | kBrokenLinearity;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kMetaShadowBeg = 0x0b0000000000ull;
static const uptr kMetaShadowEnd = 0x0d0000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x0d0000000000ull;
static const uptr kTraceMemEnd = 0x0f0000000000ull;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kShadowBeg = 0x000100000000ull;
static const uptr kShadowEnd = 0x0b0000000000ull;
static const uptr kLoAppMemBeg = 0x000000000100ull;
static const uptr kLoAppMemEnd = 0x000100000000ull;
static const uptr kHeapMemBeg = 0x0f0000000000ull;
static const uptr kHeapMemEnd = 0x0f5000000000ull;
static const uptr kHiAppMemBeg = 0x0f6000000000ull;
static const uptr kHiAppMemEnd = 0x100000000000ull; // 44 bits
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x0f0000000000ull;
static const uptr kShadowXor = 0x002100000000ull;
static const uptr kShadowAdd = 0x000000000000ull;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kVdsoBeg = 0x3c0000000000000ull;
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
};
/*
C/C++ on linux/powerpc64 (46-bit VMA)
0000 0000 1000 - 0100 0000 0000: main binary
0100 0000 0000 - 0200 0000 0000: -
0100 0000 0000 - 1000 0000 0000: shadow
1000 0000 0000 - 1000 0000 0000: -
1000 0000 0000 - 2000 0000 0000: metainfo (memory blocks and sync objects)
2000 0000 0000 - 2000 0000 0000: -
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
2000 0000 0000 - 2200 0000 0000: traces
2200 0000 0000 - 3d00 0000 0000: -
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
3d00 0000 0000 - 3e00 0000 0000: heap
3e00 0000 0000 - 3e80 0000 0000: -
3e80 0000 0000 - 4000 0000 0000: modules and main thread stack
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingPPC64_46 {
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kMetaShadowBeg = 0x100000000000ull;
static const uptr kMetaShadowEnd = 0x200000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x200000000000ull;
static const uptr kTraceMemEnd = 0x220000000000ull;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kShadowBeg = 0x010000000000ull;
static const uptr kShadowEnd = 0x100000000000ull;
static const uptr kHeapMemBeg = 0x3d0000000000ull;
static const uptr kHeapMemEnd = 0x3e0000000000ull;
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x010000000000ull;
static const uptr kHiAppMemBeg = 0x3e8000000000ull;
static const uptr kHiAppMemEnd = 0x400000000000ull; // 46 bits
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x3c0000000000ull;
static const uptr kShadowXor = 0x020000000000ull;
static const uptr kShadowAdd = 0x000000000000ull;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
static const uptr kVdsoBeg = 0x7800000000000000ull;
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
[PPC64, TSAN] LLVM basic enablement of thread sanitizer for PPC64 (BE and LE) This patch is by Simone Atzeni with portions by Adhemerval Zanella. This contains the LLVM patches to enable the thread sanitizer for PPC64, both big- and little-endian. Two different virtual memory sizes are supported: Old kernels use a 44-bit address space, while newer kernels require a 46-bit address space. There are two companion patches that will be added shortly. There is a Clang patch to actually turn on the use of the thread sanitizer for PPC64. There is also a patch that I wrote to provide interceptor support for setjmp/longjmp on PPC64. Patch discussion at reviews.llvm.org/D12841. llvm-svn: 255057
2015-12-09 05:54:39 +08:00
};
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
/*
C/C++ on linux/powerpc64 (47-bit VMA)
0000 0000 1000 - 0100 0000 0000: main binary
0100 0000 0000 - 0200 0000 0000: -
0100 0000 0000 - 1000 0000 0000: shadow
1000 0000 0000 - 1000 0000 0000: -
1000 0000 0000 - 2000 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
2000 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 2200 0000 0000: traces
2200 0000 0000 - 7d00 0000 0000: -
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
7d00 0000 0000 - 7e00 0000 0000: heap
7e00 0000 0000 - 7e80 0000 0000: -
7e80 0000 0000 - 8000 0000 0000: modules and main thread stack
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingPPC64_47 {
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
static const uptr kMetaShadowBeg = 0x100000000000ull;
static const uptr kMetaShadowEnd = 0x200000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x200000000000ull;
static const uptr kTraceMemEnd = 0x220000000000ull;
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
static const uptr kShadowBeg = 0x010000000000ull;
static const uptr kShadowEnd = 0x100000000000ull;
static const uptr kHeapMemBeg = 0x7d0000000000ull;
static const uptr kHeapMemEnd = 0x7e0000000000ull;
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x010000000000ull;
static const uptr kHiAppMemBeg = 0x7e8000000000ull;
static const uptr kHiAppMemEnd = 0x800000000000ull; // 47 bits
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0x7c0000000000ull;
static const uptr kShadowXor = 0x020000000000ull;
static const uptr kShadowAdd = 0x000000000000ull;
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
static const uptr kVdsoBeg = 0x7800000000000000ull;
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
[PowerPC][tsan] Update tsan to handle changed memory layouts in newer kernels In more recent Linux kernels with 47 bit VMAs the layout of virtual memory for powerpc64 changed causing the thread sanitizer to not work properly. This patch adds support for 47 bit VMA kernels for powerpc64. Tested on several 4.x and 3.x kernel releases. llvm-svn: 318044
2017-11-13 23:42:28 +08:00
};
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
/*
C/C++ on linux/s390x
While the kernel provides a 64-bit address space, we have to restrict ourselves
to 48 bits due to how e.g. SyncVar::GetId() works.
0000 0000 1000 - 0e00 0000 0000: binary, modules, stacks - 14 TiB
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0e00 0000 0000 - 4000 0000 0000: -
4000 0000 0000 - 8000 0000 0000: shadow - 64TiB (4 * app)
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
8000 0000 0000 - 9000 0000 0000: -
9000 0000 0000 - 9800 0000 0000: metainfo - 8TiB (0.5 * app)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
9800 0000 0000 - a000 0000 0000: -
a000 0000 0000 - b000 0000 0000: traces - 16TiB (max history * 128k threads)
b000 0000 0000 - be00 0000 0000: -
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
be00 0000 0000 - c000 0000 0000: heap - 2TiB (max supported by the allocator)
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingS390x {
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
static const uptr kMetaShadowBeg = 0x900000000000ull;
static const uptr kMetaShadowEnd = 0x980000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0xa00000000000ull;
static const uptr kTraceMemEnd = 0xb00000000000ull;
static const uptr kShadowBeg = 0x400000000000ull;
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
static const uptr kShadowEnd = 0x800000000000ull;
static const uptr kHeapMemBeg = 0xbe0000000000ull;
static const uptr kHeapMemEnd = 0xc00000000000ull;
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x0e0000000000ull;
static const uptr kHiAppMemBeg = 0xc00000004000ull;
static const uptr kHiAppMemEnd = 0xc00000004000ull;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0xb00000000000ull;
static const uptr kShadowXor = 0x100000000000ull;
static const uptr kShadowAdd = 0x000000000000ull;
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
static const uptr kVdsoBeg = 0xfffffffff000ull;
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
[TSan] Define C/C++ address ranges for SystemZ The kernel supports a full 64-bit VMA, but we can use only 48 bits due to the limitation imposed by SyncVar::GetId(). So define the address ranges similar to the other architectures, except that the address space "tail" needs to be made inaccessible in CheckAndProtect(). Since it's for only one architecture, don't make an abstraction for this. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:44:43 +08:00
};
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
/* Go on linux, darwin and freebsd on x86_64
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00c0 0000 0000: -
tsan: update Go memory mapping, Go now uses 0x00c0 heap base llvm-svn: 180113
2013-04-23 23:24:26 +08:00
00c0 0000 0000 - 00e0 0000 0000: heap
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
00e0 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 2380 0000 0000: shadow
2380 0000 0000 - 3000 0000 0000: -
tsan: refactor storage of meta information for heap blocks and sync objects The new storage (MetaMap) is based on direct shadow (instead of a hashmap + per-block lists). This solves a number of problems: - eliminates quadratic behaviour in SyncTab::GetAndLock (https://code.google.com/p/thread-sanitizer/issues/detail?id=26) - eliminates contention in SyncTab - eliminates contention in internal allocator during allocation of sync objects - removes a bunch of ad-hoc code in java interface - reduces java shadow from 2x to 1/2x - allows to memorize heap block meta info for Java and Go - allows to cleanup sync object meta info for Go - which in turn enabled deadlock detector for Go llvm-svn: 209810
2014-05-29 21:50:54 +08:00
3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
4000 0000 0000 - 6000 0000 0000: -
6000 0000 0000 - 6200 0000 0000: traces
6200 0000 0000 - 8000 0000 0000: -
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGo48 {
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kMetaShadowBeg = 0x300000000000ull;
static const uptr kMetaShadowEnd = 0x400000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x600000000000ull;
static const uptr kTraceMemEnd = 0x620000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kShadowBeg = 0x200000000000ull;
static const uptr kShadowEnd = 0x238000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x200000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
};
/* Go on windows
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00f8 0000 0000: -
00c0 0000 0000 - 00e0 0000 0000: heap
00e0 0000 0000 - 0100 0000 0000: -
0100 0000 0000 - 0500 0000 0000: shadow
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
0500 0000 0000 - 0700 0000 0000: traces
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
0700 0000 0000 - 0770 0000 0000: metainfo (memory blocks and sync objects)
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
07d0 0000 0000 - 8000 0000 0000: -
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoWindows {
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kMetaShadowBeg = 0x070000000000ull;
static const uptr kMetaShadowEnd = 0x077000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x050000000000ull;
static const uptr kTraceMemEnd = 0x070000000000ull;
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
static const uptr kShadowBeg = 0x010000000000ull;
static const uptr kShadowEnd = 0x050000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x010000000000ull;
tsan: fix windows build llvm-svn: 267681
2016-04-27 16:39:32 +08:00
};
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
/* Go on linux/powerpc64 (46-bit VMA)
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00c0 0000 0000: -
00c0 0000 0000 - 00e0 0000 0000: heap
00e0 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 2380 0000 0000: shadow
2380 0000 0000 - 2400 0000 0000: -
2400 0000 0000 - 3400 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
3400 0000 0000 - 3600 0000 0000: -
3600 0000 0000 - 3800 0000 0000: traces
3800 0000 0000 - 4000 0000 0000: -
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoPPC64_46 {
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
static const uptr kMetaShadowBeg = 0x240000000000ull;
static const uptr kMetaShadowEnd = 0x340000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x360000000000ull;
static const uptr kTraceMemEnd = 0x380000000000ull;
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
static const uptr kShadowBeg = 0x200000000000ull;
static const uptr kShadowEnd = 0x238000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x200000000000ull;
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
};
/* Go on linux/powerpc64 (47-bit VMA)
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00c0 0000 0000: -
00c0 0000 0000 - 00e0 0000 0000: heap
00e0 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 3000 0000 0000: shadow
3000 0000 0000 - 3000 0000 0000: -
3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
4000 0000 0000 - 6000 0000 0000: -
6000 0000 0000 - 6200 0000 0000: traces
6200 0000 0000 - 8000 0000 0000: -
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoPPC64_47 {
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
static const uptr kMetaShadowBeg = 0x300000000000ull;
static const uptr kMetaShadowEnd = 0x400000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x600000000000ull;
static const uptr kTraceMemEnd = 0x620000000000ull;
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
static const uptr kShadowBeg = 0x200000000000ull;
static const uptr kShadowEnd = 0x300000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x200000000000ull;
tsan: add support for linux/powerpc64 in buildgo.sh The current implementation of the Go sanitizer only works on x86_64. Added some modifications to the buildgo.sh script and the Tsan code to make it work on powerpc64/linux. Author: cseo (Carlos Eduardo Seo) Reviewed in: https://reviews.llvm.org/D43025 llvm-svn: 330122
2018-04-16 19:43:00 +08:00
};
tsan: add Go race detector support for macOS/ARM64 Add Go race detector support for macOS/ARM64. The Go counterpart is https://golang.org/cl/266373 . Author: cherry (Cherry Zhang) Reviewed-in: https://reviews.llvm.org/D90435
2020-10-31 02:42:48 +08:00
/* Go on linux/aarch64 (48-bit VMA) and darwin/aarch64 (47-bit VMA)
[compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64. Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
2018-09-19 19:56:20 +08:00
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00c0 0000 0000: -
00c0 0000 0000 - 00e0 0000 0000: heap
00e0 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 3000 0000 0000: shadow
3000 0000 0000 - 3000 0000 0000: -
3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
4000 0000 0000 - 6000 0000 0000: -
6000 0000 0000 - 6200 0000 0000: traces
6200 0000 0000 - 8000 0000 0000: -
[compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64. Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
2018-09-19 19:56:20 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoAarch64 {
[compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64. Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
2018-09-19 19:56:20 +08:00
static const uptr kMetaShadowBeg = 0x300000000000ull;
static const uptr kMetaShadowEnd = 0x400000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x600000000000ull;
static const uptr kTraceMemEnd = 0x620000000000ull;
[compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64. Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
2018-09-19 19:56:20 +08:00
static const uptr kShadowBeg = 0x200000000000ull;
static const uptr kShadowEnd = 0x300000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x200000000000ull;
[compiler-rt][TSan] Add TSan runtime support for Go on linux-aarch64. Summary: This patch adds TSan runtime support for Go on linux-aarch64 platforms. This enables people working on golang to implement their platform/language part of the TSan support. Basic testing is done with lib/tsan/go/buildgo.sh. Additional testing will be done as part of the work done in the Go project. It is intended to support other VMA sizes, except 39 which does not have enough bits to support the Go heap requirements. Patch by Fangming Fang <Fangming.Fang@arm.com>. Reviewers: kubamracek, dvyukov, javed.absar Subscribers: mcrosier, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D52167 llvm-svn: 342541
2018-09-19 19:56:20 +08:00
};
tsan: add mips64 support in lib/tsan/go/buildgo.sh Enable mips64 support in buildgo.sh. Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D90130
2020-10-26 19:18:54 +08:00
/*
Go on linux/mips64 (47-bit VMA)
0000 0000 1000 - 0000 1000 0000: executable
0000 1000 0000 - 00c0 0000 0000: -
00c0 0000 0000 - 00e0 0000 0000: heap
00e0 0000 0000 - 2000 0000 0000: -
2000 0000 0000 - 3000 0000 0000: shadow
3000 0000 0000 - 3000 0000 0000: -
3000 0000 0000 - 4000 0000 0000: metainfo (memory blocks and sync objects)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
4000 0000 0000 - 6000 0000 0000: -
6000 0000 0000 - 6200 0000 0000: traces
6200 0000 0000 - 8000 0000 0000: -
tsan: add mips64 support in lib/tsan/go/buildgo.sh Enable mips64 support in buildgo.sh. Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D90130
2020-10-26 19:18:54 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoMips64_47 {
tsan: add mips64 support in lib/tsan/go/buildgo.sh Enable mips64 support in buildgo.sh. Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D90130
2020-10-26 19:18:54 +08:00
static const uptr kMetaShadowBeg = 0x300000000000ull;
static const uptr kMetaShadowEnd = 0x400000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0x600000000000ull;
static const uptr kTraceMemEnd = 0x620000000000ull;
tsan: add mips64 support in lib/tsan/go/buildgo.sh Enable mips64 support in buildgo.sh. Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D90130
2020-10-26 19:18:54 +08:00
static const uptr kShadowBeg = 0x200000000000ull;
static const uptr kShadowEnd = 0x300000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x00e000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x200000000000ull;
tsan: add mips64 support in lib/tsan/go/buildgo.sh Enable mips64 support in buildgo.sh. Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D90130
2020-10-26 19:18:54 +08:00
};
[sanitizers] Enable runtime vma for mips64 in buildgo.sh Go requires 47 bits VA for tsan. Go will run race_detector testcases unless tsan warns about "unsupported VMA range" Author: mzh (Meng Zhuo) Reviewed-in: https://reviews.llvm.org/D98238
2021-03-09 18:44:23 +08:00
[TSan] Add SystemZ SANITIZER_GO support Define the address ranges (similar to the C/C++ ones, but with the heap range merged into the app range) and enable the sanity check. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:49:30 +08:00
/*
Go on linux/s390x
0000 0000 1000 - 1000 0000 0000: executable and heap - 16 TiB
1000 0000 0000 - 4000 0000 0000: -
4000 0000 0000 - 8000 0000 0000: shadow - 64TiB (4 * app)
8000 0000 0000 - 9000 0000 0000: -
9000 0000 0000 - 9800 0000 0000: metainfo - 8TiB (0.5 * app)
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
9800 0000 0000 - a000 0000 0000: -
a000 0000 0000 - b000 0000 0000: traces - 16TiB (max history * 128k threads)
[TSan] Add SystemZ SANITIZER_GO support Define the address ranges (similar to the C/C++ ones, but with the heap range merged into the app range) and enable the sanity check. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:49:30 +08:00
*/
tsan: make all memory mappings testable Currently we define/compile the mapping for a platform only on that platform. This makes it impossible to unit-test them on a single platform, and even to build test. We have 17 of them and the Go mappings will be tested only after a manual episodic update of the Go runtime. Define all mappings always with unique names. This will allow to unit-test them. No functional changes. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107734
2021-08-07 18:03:24 +08:00
struct MappingGoS390x {
[TSan] Add SystemZ SANITIZER_GO support Define the address ranges (similar to the C/C++ ones, but with the heap range merged into the app range) and enable the sanity check. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:49:30 +08:00
static const uptr kMetaShadowBeg = 0x900000000000ull;
static const uptr kMetaShadowEnd = 0x980000000000ull;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
static const uptr kTraceMemBeg = 0xa00000000000ull;
static const uptr kTraceMemEnd = 0xb00000000000ull;
[TSan] Add SystemZ SANITIZER_GO support Define the address ranges (similar to the C/C++ ones, but with the heap range merged into the app range) and enable the sanity check. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:49:30 +08:00
static const uptr kShadowBeg = 0x400000000000ull;
static const uptr kShadowEnd = 0x800000000000ull;
tsan: rename kAppMemBeg to kLoAppMemBeg Unify Go mapping naming with C++ naming to allow writing portable code/tests that can work for both C++ and Go. No functional changes. Depends on D107737. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107738
2021-08-07 20:06:43 +08:00
static const uptr kLoAppMemBeg = 0x000000001000ull;
static const uptr kLoAppMemEnd = 0x100000000000ull;
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
static const uptr kMidAppMemBeg = 0;
static const uptr kMidAppMemEnd = 0;
static const uptr kHiAppMemBeg = 0;
static const uptr kHiAppMemEnd = 0;
static const uptr kHeapMemBeg = 0;
static const uptr kHeapMemEnd = 0;
static const uptr kVdsoBeg = 0;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
static const uptr kShadowMsk = 0;
static const uptr kShadowXor = 0;
static const uptr kShadowAdd = 0x400000000000ull;
[TSan] Add SystemZ SANITIZER_GO support Define the address ranges (similar to the C/C++ ones, but with the heap range merged into the app range) and enable the sanity check. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D105629
2021-07-02 08:49:30 +08:00
};
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
extern uptr vmaSize;
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
template <typename Func, typename Arg>
ALWAYS_INLINE auto SelectMapping(Arg arg) {
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
#if SANITIZER_GO
# if defined(__powerpc64__)
switch (vmaSize) {
case 46:
return Func::template Apply<MappingGoPPC64_46>(arg);
case 47:
return Func::template Apply<MappingGoPPC64_47>(arg);
}
# elif defined(__mips64)
return Func::template Apply<MappingGoMips64_47>(arg);
# elif defined(__s390x__)
return Func::template Apply<MappingGoS390x>(arg);
# elif defined(__aarch64__)
return Func::template Apply<MappingGoAarch64>(arg);
# elif SANITIZER_WINDOWS
return Func::template Apply<MappingGoWindows>(arg);
# else
return Func::template Apply<MappingGo48>(arg);
# endif
#else // SANITIZER_GO
tsan: fix active mapping selection Fix bug introduced by commit 5d106f16b972. SANITIZER_IOSSIM is always defined, it's the value 0/1 that's meaningful. Reviewed By: DavidSpickett Differential Revision: https://reviews.llvm.org/D107888
2021-08-11 18:39:38 +08:00
# if defined(__x86_64__) || SANITIZER_IOSSIM || SANITIZER_MAC && !SANITIZER_IOS
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<Mapping48AddressSpace>(arg);
# elif defined(__aarch64__) && defined(__APPLE__)
return Func::template Apply<MappingAppleAarch64>(arg);
# elif defined(__aarch64__) && !defined(__APPLE__)
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
switch (vmaSize) {
case 39:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingAarch64_39>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
case 42:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingAarch64_42>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
case 48:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingAarch64_48>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
# elif defined(__powerpc64__)
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
switch (vmaSize) {
case 44:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingPPC64_44>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
case 46:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingPPC64_46>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
case 47:
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
return Func::template Apply<MappingPPC64_47>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
# elif defined(__mips64)
return Func::template Apply<MappingMips64_40>(arg);
# elif defined(__s390x__)
return Func::template Apply<MappingS390x>(arg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
# else
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
# error "unsupported platform"
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
# endif
#endif
tsan: remove indirection when selecting the active mapping Currently there are 2 levels when selecting the active mapping: the branchy ifdef tree + another ifdef tree in SelectMapping. Moreover, there is an additional indirection for some platforms via HAS_48_BIT_ADDRESS_SPACE define. This makes already complex logic even more complex and almost impossible to read. Remove one level of indirection and define the active mapping in SelectMapping. Depends on D107742. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107743
2021-08-08 02:10:54 +08:00
Die();
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
tsan: unit-test all mappings Move the mapping checking logic from startup to unit tests and test all mapping instead of just the active one. This makes it much more feasible to make any global changes to the mappings since we have 17 of them. Depends on D107740. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107741
2021-08-07 19:07:00 +08:00
template <typename Func>
void ForEachMapping() {
Func::template Apply<Mapping48AddressSpace>();
Func::template Apply<MappingMips64_40>();
Func::template Apply<MappingAppleAarch64>();
Func::template Apply<MappingAarch64_39>();
Func::template Apply<MappingAarch64_42>();
Func::template Apply<MappingAarch64_48>();
Func::template Apply<MappingPPC64_44>();
Func::template Apply<MappingPPC64_46>();
Func::template Apply<MappingPPC64_47>();
Func::template Apply<MappingS390x>();
Func::template Apply<MappingGo48>();
Func::template Apply<MappingGoWindows>();
Func::template Apply<MappingGoPPC64_46>();
Func::template Apply<MappingGoPPC64_47>();
Func::template Apply<MappingGoAarch64>();
Func::template Apply<MappingGoMips64_47>();
Func::template Apply<MappingGoS390x>();
}
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
enum MappingType {
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
kLoAppMemBeg,
kLoAppMemEnd,
kHiAppMemBeg,
kHiAppMemEnd,
kMidAppMemBeg,
kMidAppMemEnd,
kHeapMemBeg,
kHeapMemEnd,
kShadowBeg,
kShadowEnd,
kMetaShadowBeg,
kMetaShadowEnd,
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
kTraceMemBeg,
kTraceMemEnd,
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
kVdsoBeg,
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
};
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct MappingField {
template <typename Mapping>
static uptr Apply(MappingType type) {
switch (type) {
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
case kLoAppMemBeg:
return Mapping::kLoAppMemBeg;
case kLoAppMemEnd:
return Mapping::kLoAppMemEnd;
case kMidAppMemBeg:
return Mapping::kMidAppMemBeg;
case kMidAppMemEnd:
return Mapping::kMidAppMemEnd;
case kHiAppMemBeg:
return Mapping::kHiAppMemBeg;
case kHiAppMemEnd:
return Mapping::kHiAppMemEnd;
case kHeapMemBeg:
return Mapping::kHeapMemBeg;
case kHeapMemEnd:
return Mapping::kHeapMemEnd;
case kVdsoBeg:
return Mapping::kVdsoBeg;
case kShadowBeg:
return Mapping::kShadowBeg;
case kShadowEnd:
return Mapping::kShadowEnd;
case kMetaShadowBeg:
return Mapping::kMetaShadowBeg;
case kMetaShadowEnd:
return Mapping::kMetaShadowEnd;
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
case kTraceMemBeg:
return Mapping::kTraceMemBeg;
case kTraceMemEnd:
return Mapping::kTraceMemEnd;
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
tsan: define all fields for all mappings Define all fields to 0 for all mappings. This allows to write portable code and tests. For all existing cases 0 values work out of the box because we check if an address belongs to the range and nothing belongs to [0, 0] range. Depends on D107738. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107739
2021-08-07 20:19:17 +08:00
Die();
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
}
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
};
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr LoAppMemBeg(void) { return SelectMapping<MappingField>(kLoAppMemBeg); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr LoAppMemEnd(void) { return SelectMapping<MappingField>(kLoAppMemEnd); }
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr MidAppMemBeg(void) { return SelectMapping<MappingField>(kMidAppMemBeg); }
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr MidAppMemEnd(void) { return SelectMapping<MappingField>(kMidAppMemEnd); }
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr HeapMemBeg(void) { return SelectMapping<MappingField>(kHeapMemBeg); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr HeapMemEnd(void) { return SelectMapping<MappingField>(kHeapMemEnd); }
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr HiAppMemBeg(void) { return SelectMapping<MappingField>(kHiAppMemBeg); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr HiAppMemEnd(void) { return SelectMapping<MappingField>(kHiAppMemEnd); }
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr VdsoBeg(void) { return SelectMapping<MappingField>(kVdsoBeg); }
tsan: add description of memory layouts in different configs llvm-svn: 168777
2012-11-28 15:44:26 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr ShadowBeg(void) { return SelectMapping<MappingField>(kShadowBeg); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr ShadowEnd(void) { return SelectMapping<MappingField>(kShadowEnd); }
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr MetaShadowBeg(void) { return SelectMapping<MappingField>(kMetaShadowBeg); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: rename mapping field selectors Rename mapping field selectors according to the code style. Reuse the actual field names, there is no need to invent second set of names. Depends on D107743. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107744
2021-08-08 02:18:37 +08:00
uptr MetaShadowEnd(void) { return SelectMapping<MappingField>(kMetaShadowEnd); }
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
ALWAYS_INLINE
uptr TraceMemBeg(void) { return SelectMapping<MappingField>(kTraceMemBeg); }
ALWAYS_INLINE
uptr TraceMemEnd(void) { return SelectMapping<MappingField>(kTraceMemEnd); }
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct IsAppMemImpl {
template <typename Mapping>
static bool Apply(uptr mem) {
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
return (mem >= Mapping::kHeapMemBeg && mem < Mapping::kHeapMemEnd) ||
[compiler-rt] [tsan] Add support for PIE build on AArch64 This patch adds PIE executable support for aarch64-linux. It adds two more segments: - 0x05500000000-0x05600000000: 39-bits PIE program segments - 0x2aa00000000-0x2ab00000000: 42-bits PIE program segments Fortunately it is possible to use the same transformation formula for the new segments range with some adjustments in shadow to memory formula (it adds a constant offset based on the VMA size). A simple testcase is also added, however it is disabled on x86 due the fact it might fail on newer kernels [1]. [1] https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90 llvm-svn: 256184
2015-12-22 03:27:57 +08:00
(mem >= Mapping::kMidAppMemBeg && mem < Mapping::kMidAppMemEnd) ||
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
(mem >= Mapping::kLoAppMemBeg && mem < Mapping::kLoAppMemEnd) ||
(mem >= Mapping::kHiAppMemBeg && mem < Mapping::kHiAppMemEnd);
tsan: Enable 48-bit VMA support on aarch64 This patch adds 48-bits VMA support for tsan on aarch64. As current mappings for aarch64, 48-bit VMA also supports PIE executable. This limits the mapping mechanism because the PIE address bits (usually 0aaaaXXXXXXXX) makes it harder to create a mask/xor value to include all memory regions. I think it is possible to create a large application VAM range by either dropping PIE support or tune current range. It also changes slight the way addresses are packed in SyncVar structure: previously it assumes x86_64 as the maximum VMA range. Since ID is 14 bits wide, shifting 48 bits should be ok. Tested on x86_64, ppc64le and aarch64 (39 and 48 bits VMA). llvm-svn: 277137
2016-07-29 20:45:35 +08:00
}
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
};
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
ALWAYS_INLINE
bool IsAppMem(uptr mem) { return SelectMapping<IsAppMemImpl>(mem); }
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct IsShadowMemImpl {
template <typename Mapping>
static bool Apply(uptr mem) {
return mem >= Mapping::kShadowBeg && mem <= Mapping::kShadowEnd;
}
};
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: introduce RawShadow type Currently we hardcode u64 type for shadow everywhere and do lots of uptr<->u64* casts. It makes it hard to change u64 to another type (e.g. u32) and makes it easy to introduce bugs. Introduce RawShadow type and use it in MemToShadow, ShadowToMem, IsShadowMem and throughout the code base as u64 replacement. This makes it possible to change u64 to something else in future and generally improves static typing. Depends on D107481. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107482
2021-08-05 00:55:00 +08:00
bool IsShadowMem(RawShadow *p) {
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
return SelectMapping<IsShadowMemImpl>(reinterpret_cast<uptr>(p));
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
}
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct IsMetaMemImpl {
template <typename Mapping>
static bool Apply(uptr mem) {
return mem >= Mapping::kMetaShadowBeg && mem <= Mapping::kMetaShadowEnd;
}
};
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: make IsMetaMem accept u32* MemToMeta returns u32*, so it's reasonable for IsMetaMem to accept u32* as well. Changing the argument type just removes few type casts. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107481
2021-08-05 00:27:53 +08:00
bool IsMetaMem(const u32 *p) {
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
return SelectMapping<IsMetaMemImpl>(reinterpret_cast<uptr>(p));
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
}
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct MemToShadowImpl {
template <typename Mapping>
static uptr Apply(uptr x) {
DCHECK(IsAppMemImpl::Apply<Mapping>(x));
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
return (((x) & ~(Mapping::kShadowMsk | (kShadowCell - 1))) ^
Mapping::kShadowXor) *
tsan: fix latent bug in shadow computation We use kShadowCnt (number of shadow cells per application granule) when computing shadow, but it's wrong. We need the ratio between shadow and app memory (how much shadow is larger than app memory), which is kShadowMultiplier. Currently both are equal to 4, so it works fine. Use the correct constant. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D108033
2021-08-13 21:24:23 +08:00
kShadowMultiplier +
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
Mapping::kShadowAdd;
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
};
tsan: introduce RawShadow type Currently we hardcode u64 type for shadow everywhere and do lots of uptr<->u64* casts. It makes it hard to change u64 to another type (e.g. u32) and makes it easy to introduce bugs. Introduce RawShadow type and use it in MemToShadow, ShadowToMem, IsShadowMem and throughout the code base as u64 replacement. This makes it possible to change u64 to something else in future and generally improves static typing. Depends on D107481. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107482
2021-08-05 00:55:00 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: introduce RawShadow type Currently we hardcode u64 type for shadow everywhere and do lots of uptr<->u64* casts. It makes it hard to change u64 to another type (e.g. u32) and makes it easy to introduce bugs. Introduce RawShadow type and use it in MemToShadow, ShadowToMem, IsShadowMem and throughout the code base as u64 replacement. This makes it possible to change u64 to something else in future and generally improves static typing. Depends on D107481. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107482
2021-08-05 00:55:00 +08:00
RawShadow *MemToShadow(uptr x) {
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
return reinterpret_cast<RawShadow *>(SelectMapping<MemToShadowImpl>(x));
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
}
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct MemToMetaImpl {
template <typename Mapping>
static u32 *Apply(uptr x) {
DCHECK(IsAppMemImpl::Apply<Mapping>(x));
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
return (u32 *)(((((x) & ~(Mapping::kShadowMsk | (kMetaShadowCell - 1)))) /
kMetaShadowCell * kMetaShadowSize) |
Mapping::kMetaShadowBeg);
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
};
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
ALWAYS_INLINE
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
u32 *MemToMeta(uptr x) { return SelectMapping<MemToMetaImpl>(x); }
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
struct ShadowToMemImpl {
template <typename Mapping>
static uptr Apply(uptr sp) {
tsan: unit-test all mappings Move the mapping checking logic from startup to unit tests and test all mapping instead of just the active one. This makes it much more feasible to make any global changes to the mappings since we have 17 of them. Depends on D107740. Reviewed By: vitalybuka, melver Differential Revision: https://reviews.llvm.org/D107741
2021-08-07 19:07:00 +08:00
if (!IsShadowMemImpl::Apply<Mapping>(sp))
return 0;
// The shadow mapping is non-linear and we've lost some bits, so we don't
// have an easy way to restore the original app address. But the mapping is
// a bijection, so we try to restore the address as belonging to
// low/mid/high range consecutively and see if shadow->app->shadow mapping
// gives us the same address.
tsan: fix latent bug in shadow computation We use kShadowCnt (number of shadow cells per application granule) when computing shadow, but it's wrong. We need the ratio between shadow and app memory (how much shadow is larger than app memory), which is kShadowMultiplier. Currently both are equal to 4, so it works fine. Use the correct constant. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D108033
2021-08-13 21:24:23 +08:00
uptr p =
((sp - Mapping::kShadowAdd) / kShadowMultiplier) ^ Mapping::kShadowXor;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
if (p >= Mapping::kLoAppMemBeg && p < Mapping::kLoAppMemEnd &&
tsan: remove TSAN_MID_APP_RANGE macro First, the define conflicts with definition/testing of all mappings, since it's not a global property anymore. Second, macros/ifdefs are bad. Define kMidAppMemBeg/End to 0 to denote that there is no "mid" range instead. Depends on D107736. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107737
2021-08-07 19:39:58 +08:00
MemToShadowImpl::Apply<Mapping>(p) == sp)
return p;
tsan: unify all shadow mappings Currently we have ifdef's for Go/C++ and Windows/non-Windows in MemToShadow, MemToMeta, ShadowToMem. This does not allow to test all mappings on a single platform. Make all these functions support a superset of mappings for all platforms by defining missing mapping consts to 0. E.g. we always do ^A+B, but if A and B are defined to 0, then these operations become no-op. Depends on D107739. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107740
2021-08-07 22:05:15 +08:00
if (Mapping::kMidAppMemBeg) {
uptr p_mid = p + (Mapping::kMidAppMemBeg & Mapping::kShadowMsk);
if (p_mid >= Mapping::kMidAppMemBeg && p_mid < Mapping::kMidAppMemEnd &&
MemToShadowImpl::Apply<Mapping>(p_mid) == sp)
return p_mid;
}
return p | Mapping::kShadowMsk;
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
}
};
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
ALWAYS_INLINE
tsan: introduce RawShadow type Currently we hardcode u64 type for shadow everywhere and do lots of uptr<->u64* casts. It makes it hard to change u64 to another type (e.g. u32) and makes it easy to introduce bugs. Introduce RawShadow type and use it in MemToShadow, ShadowToMem, IsShadowMem and throughout the code base as u64 replacement. This makes it possible to change u64 to something else in future and generally improves static typing. Depends on D107481. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D107482
2021-08-05 00:55:00 +08:00
uptr ShadowToMem(RawShadow *s) {
tsan: deduplicate mapping selection Currently we have mapping selection duplicated 9 times. Deduplicate it. No functional changes. Depends on D107734. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107735
2021-08-07 18:57:24 +08:00
return SelectMapping<ShadowToMemImpl>(reinterpret_cast<uptr>(s));
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
}
tsan: add notion of compressed addresses New tsan runtime will need to compress addresses/PCs to fewer bits. Add CompressAddr/RestoreAddr functions that compress/restore addresses to 44 bits. Depends on D107744. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107745
2021-08-08 03:05:59 +08:00
// Compresses addr to kCompressedAddrBits stored in least significant bits.
ALWAYS_INLINE uptr CompressAddr(uptr addr) {
return addr & ((1ull << kCompressedAddrBits) - 1);
}
struct RestoreAddrImpl {
typedef uptr Result;
template <typename Mapping>
static Result Apply(uptr addr) {
// To restore the address we go over all app memory ranges and check if top
// 3 bits of the compressed addr match that of the app range. If yes, we
// assume that the compressed address come from that range and restore the
// missing top bits to match the app range address.
tsan: don't use symbol binding 10 Building Go programs with the current runtime fails with: loadelf: race_linux_amd64: malformed elf file: _ZZN6__tsan15RestoreAddrImpl5ApplyINS_11MappingGo48EEEmmE6ranges: invalid symbol binding 10 Go linker does not understand ELF in all its generality. Don't use static const data in inline methods. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D112434
2021-10-24 15:22:58 +08:00
const uptr ranges[] = {
tsan: add notion of compressed addresses New tsan runtime will need to compress addresses/PCs to fewer bits. Add CompressAddr/RestoreAddr functions that compress/restore addresses to 44 bits. Depends on D107744. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107745
2021-08-08 03:05:59 +08:00
Mapping::kLoAppMemBeg, Mapping::kLoAppMemEnd, Mapping::kMidAppMemBeg,
Mapping::kMidAppMemEnd, Mapping::kHiAppMemBeg, Mapping::kHiAppMemEnd,
Mapping::kHeapMemBeg, Mapping::kHeapMemEnd,
};
const uptr indicator = 0x0e0000000000ull;
const uptr ind_lsb = 1ull << LeastSignificantSetBitIndex(indicator);
for (uptr i = 0; i < ARRAY_SIZE(ranges); i += 2) {
uptr beg = ranges[i];
uptr end = ranges[i + 1];
if (beg == end)
continue;
for (uptr p = beg; p < end; p = RoundDown(p + ind_lsb, ind_lsb)) {
if ((addr & indicator) == (p & indicator))
return addr | (p & ~(ind_lsb - 1));
}
}
tsan: fix Printf format string Reported on D107745 Reported-by: Wolfgang Pieb (wolfgangp) Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107881
2021-08-11 14:28:01 +08:00
Printf("ThreadSanitizer: failed to restore address 0x%zx\n", addr);
tsan: add notion of compressed addresses New tsan runtime will need to compress addresses/PCs to fewer bits. Add CompressAddr/RestoreAddr functions that compress/restore addresses to 44 bits. Depends on D107744. Reviewed By: melver Differential Revision: https://reviews.llvm.org/D107745
2021-08-08 03:05:59 +08:00
Die();
}
};
// Restores compressed addr from kCompressedAddrBits to full representation.
// This is called only during reporting and is not performance-critical.
inline uptr RestoreAddr(uptr addr) {
return SelectMapping<RestoreAddrImpl>(addr);
}
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
// The additional page is to catch shadow stack overflow as paging fault.
// Windows wants 64K alignment for mmaps.
const uptr kTotalTraceSize = (kTraceSize * sizeof(Event) + sizeof(Trace)
+ (64 << 10) + (64 << 10) - 1) & ~((64 << 10) - 1);
struct GetThreadTraceImpl {
template <typename Mapping>
static uptr Apply(uptr tid) {
uptr p = Mapping::kTraceMemBeg + tid * kTotalTraceSize;
DCHECK_LT(p, Mapping::kTraceMemEnd);
return p;
}
};
ALWAYS_INLINE
uptr GetThreadTrace(int tid) { return SelectMapping<GetThreadTraceImpl>(tid); }
struct GetThreadTraceHeaderImpl {
template <typename Mapping>
static uptr Apply(uptr tid) {
uptr p = Mapping::kTraceMemBeg + tid * kTotalTraceSize +
kTraceSize * sizeof(Event);
DCHECK_LT(p, Mapping::kTraceMemEnd);
return p;
}
};
ALWAYS_INLINE
uptr GetThreadTraceHeader(int tid) {
return SelectMapping<GetThreadTraceHeaderImpl>(tid);
}
tsan: support mmap(MAP_32BIT) Allow user memory in the first TB of address space. This also enabled non-pie binaries and freebsd. Fixes issue: https://code.google.com/p/thread-sanitizer/issues/detail?id=5 llvm-svn: 220571
2014-10-25 01:07:29 +08:00
void InitializePlatform();
[compiler-rt] [tsan] Unify aarch64 mapping This patch unify the 39 and 42-bit support for AArch64 by using an external memory read to check the runtime detected VMA and select the better mapping and transformation. Although slower, this leads to same instrumented binary to be independent of the kernel. Along with this change this patch also fix some 42-bit failures with ALSR disable by increasing the upper high app memory threshold and also the 42-bit madvise value for non large page set. llvm-svn: 254151
2015-11-26 21:10:47 +08:00
void InitializePlatformEarly();
[tsan] Shadow memory setup for OS X Updating the shadow memory initialization in `tsan_platform_mac.cc` to also initialize the meta shadow and to mprotect the memory ranges that need to be avoided. Differential Revision: http://reviews.llvm.org/D14324 llvm-svn: 252044
2015-11-04 19:39:40 +08:00
void CheckAndProtect();
void InitializeShadowMemoryPlatform();
Revert "tsan: new runtime (v3)" Summary: This reverts commit ac95b8d9548cb3c07e60236d3e9e1fd05f79579b. There is a number of bot failures: http://45.33.8.238/mac/38755/step_4.txt https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/38135/consoleFull#-148886289949ba4694-19c4-4d7e-bec5-911270d8a58c Reviewers: vitalybuka, melver Subscribers:
2021-11-13 00:43:26 +08:00
void FlushShadowMemory();
tsan: write uptime in mem profile Write uptime in real time seconds for every mem profile record. Uptime is useful to make more sense out of the profile, compare random lines, etc. Depends on D110153. Reviewed By: melver, vitalybuka Differential Revision: https://reviews.llvm.org/D110154
2021-09-21 19:09:31 +08:00
void WriteMemoryProfile(char *buf, uptr buf_size, u64 uptime_ns);
tsan: intercept libc __res_iclose this is required to catch close of file descriptors created in getaddrinfo() llvm-svn: 174624
2013-02-07 23:27:45 +08:00
int ExtractResolvFDs(void *state, int *fds, int nfd);
tsan: add support for passing file descriptors over UNIX domain sockets tsan was missing new fd's arrived from recvmsg(), and thus was reporting false positives due to missed synchronization on the fd's llvm-svn: 195914
2013-11-28 17:09:42 +08:00
int ExtractRecvmsgFDs(void *msg, int *fds, int nfd);
[TSan] Improve handling of stack pointer mangling in {set,long}jmp, pt.7 Factor out `ExtractLongJmpSp` helper function and move platform-specific code to tsan_platform_{linux,mac}.cc. Reviewed By: dvyukov Differential Revision: https://reviews.llvm.org/D64050 llvm-svn: 364947
2019-07-03 01:32:04 +08:00
uptr ExtractLongJmpSp(uptr *env);
Don't require ThreadState to be contained within tls on all platforms The existing implementation ran CHECKs to assert that the thread state was stored inside the tls. However, the mac implementation of tsan doesn't store the thread state in tls, so these checks fail once darwin tls support is added to the sanitizers. Only run these checks on platforms where the thread state is expected to be contained in the tls. llvm-svn: 303886
2017-05-26 01:41:10 +08:00
void ImitateTlsWrite(ThreadState *thr, uptr tls_addr, uptr tls_size);
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
[NFC][tsan] Simplify call_pthread_cancel_with_cleanup
2020-11-16 19:00:30 +08:00
int call_pthread_cancel_with_cleanup(int (*fn)(void *arg),
void (*cleanup)(void *arg), void *arg);
Move pthread_cond_* interceptors from sanitizer_common with all the ugly hacks to TSan llvm-svn: 206423
2014-04-17 07:06:46 +08:00
Revert "tsan: fix leak of ThreadSignalContext for fibers" Temporarily revert "tsan: fix leak of ThreadSignalContext for fibers" because it breaks the LLDB bot on GreenDragon. This reverts commit 93f7743851b7a01a8c8f54b3753b6e5cd5591e15. This reverts commit d8a0f76de7bd98dc7a271bc15b39a4cdbfdf6ecb.
2020-03-26 10:18:01 +08:00
void DestroyThreadState();
tsan: fix leak of ThreadSignalContext memory mapping when destroying fibers When creating and destroying fibers in tsan a thread state is created and destroyed. Currently, a memory mapping is leaked with each fiber (in __tsan_destroy_fiber). This causes applications with many short running fibers to crash or hang because of linux vm.max_map_count. The root of this is that ThreadState holds a pointer to ThreadSignalContext for handling signals. The initialization and destruction of it is tied to platform specific events in tsan_interceptors_posix and missed when destroying a fiber (specifically, SigCtx is used to lazily create the ThreadSignalContext in tsan_interceptors_posix). This patch cleans up the memory by makinh the ThreadState create and destroy the ThreadSignalContext. The relevant code causing the leak with fibers is the fiber destruction: void FiberDestroy(ThreadState *thr, uptr pc, ThreadState *fiber) { FiberSwitchImpl(thr, fiber); ThreadFinish(fiber); FiberSwitchImpl(fiber, thr); internal_free(fiber); } Author: Florian Reviewed-in: https://reviews.llvm.org/D76073
2020-04-11 15:52:13 +08:00
void PlatformCleanUpThreadState(ThreadState *thr);
[tsan] Handle libdispatch worker threads on OS X On OS X, GCD worker threads are created without a call to pthread_create. We need to properly register these threads with ThreadCreate and ThreadStart. This patch uses a libpthread API (`pthread_introspection_hook_install`) to get notifications about new threads and about threads that are about to be destroyed. Differential Revision: http://reviews.llvm.org/D14328 llvm-svn: 252049
2015-11-04 23:09:14 +08:00
[tsan] First commit of ThreadSanitizer (TSan) run-time library. Algorithm description: http://code.google.com/p/thread-sanitizer/wiki/ThreadSanitizerAlgorithm Status: The tool is known to work on large real-life applications, but still has quite a few rough edges. Nothing is guaranteed yet. The tool works on x86_64 Linux. Support for 64-bit MacOS 10.7+ is planned for late 2012. Support for 32-bit OSes is doable, but problematic and not yet planed. Further commits coming: - tests - makefiles - documentation - clang driver patch The code was previously developed at http://code.google.com/p/data-race-test/source/browse/trunk/v2/ by Dmitry Vyukov and Kostya Serebryany with contributions from Timur Iskhodzhanov, Alexander Potapenko, Alexey Samsonov and Evgeniy Stepanov. llvm-svn: 156542
2012-05-10 21:48:04 +08:00
} // namespace __tsan
tsan: port Go runtime to Darwin llvm-svn: 160266
2012-07-16 21:02:40 +08:00
#endif // TSAN_PLATFORM_H