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? > 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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
