On Fri, Feb 24, 2017 at 9:24 PM, Owen Waller <[email protected]> wrote: > Hi Dimitry, > > > If there is somebody who is willing to work on this, then yes. Otherwise, > maybe. > > > I have created https://github.com/golang/go/issues/19273 in order to track > this. > > 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. > Maybe it's possible to stub the i2c part? That would make testing much > simpler regardless of tsan. > > > In this specific case, maybe, yes. It's not my i2c drier so just how much > work and how much change would be required I'd need to investigate. > > 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.
