Hi Dimitry, > > > > ThreadSanitizer does not work on any 32-bit platforms. It assumes that > > it can reserve huge continuous chunks of address space for various > > things. > > > > > > > > > > > > Tsan reserves 4X for shadow memory (where X is amount of memory where > > > > user data resides), 0.5X for another shadow memory, 1TB for heap and > > 128GB for thread info. You can see the details in > > llvm/projects/compiler-rt/lib/tsan/rtl/tsan_platform.h. > > > > > > > > Those ranges are well beyond the 32-bit address space. But, having had a > > > > quick look at the tsan_platform.h file. It looks like the file contains > > > > memory layouts for hardware with 39, 42, 44, 46 and 64 bit address spaces, > > at least for C/C++ programs if not Go. > > > > > > Given that these ranges are just defined as constants in the code is there a > > > > fundamental reason why these ranges could not be shrunk to fit into a 32 bit > > > > address space? Does the tread sanitizer require some (assembly) instructions > > that are only found in 64 bit hardware for example? > > No fundamental reason. > Tsan requires 64-bit atomic loads and stores.
This leads me to ask two things. Why are 64-bit atomic load and stores required? To take an example. ARM6 cores have have load stores for a very long time[1]. But being a 32-bit core that's usually attached to a 32 bit memory bus, the instructions are 32-bit. So is it just that an atomic pair of load and store operations are required? I am of course assuming that gcc or clang on these platforms can make use of these instructions. If all that is needed are atomic loads and stores then that leads to the second question. Why hasn't a 32-bit port (with a reduced memory map) of the thread sanitizer already appeared? There are lots of other 32 bit cores with atomic load sores - MIPS32, PPC, SPARC etc... At the minute I feel I am missing something _very_ important. Otherwise this looks like it should be a solved problem. [1] http://infocenter.arm.com/help/topic/com.arm.doc.dht0008a/DHT0008A_ arm_synchronization_primitives.pdf Section 1.2 Owen -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
