On Fri, Feb 24, 2017 at 11:24 PM, Owen Waller <go-n...@kulawe.com> wrote: > 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.
Yes, it needs just atomic loads and stores. > 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. A 32-bit version would be quite restrictive wrt the amount of memory an app can use. Tsan can have up to 10x overhead, with Go's GC overhead this goes to up to 20x. But I think the real reason is that nobody was interested enough in it to implement it. There can also be some hidden problems that I don't see (we never seriously considered porting tsan to 32-bits). -- 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
