On Tue, Feb 28, 2017 at 2:44 AM, Owen Waller <go-n...@kulawe.com> wrote: > 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. > > > Good, so in theory almost any modern processor architecture can be > supported. > > > 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). > > > So next dumb question. > > How did you work out the memory mappings for 64-bit systems
The make goal of the current mapping is to make MemToShadow function fast (no memory accesses, no branching). For starters you can take any simple mapping at the cost making MemToShadow slower. > and do you want > to take a stab at what the mappings might be for a 32 bit system? I don't have time to work on this. > I know the > memory map will be smaller and it will restrict things but it might be > enough for what I need (and possibly others working on small embedded > hardware). > > But this seems to be heading towards a conclusion of. "Somebody just needs > to try it, and see what happens." > So in that case: > > a) What do I need to do to rebuild the lib? So I need clang or will gcc do? > b) Is the library difficult to rebuild? Is there anything special I need to > know? You need clang as it contains the master copy of tsan runtime. Here are some building instructions: https://github.com/google/sanitizers/wiki/AddressSanitizerHowToBuild > c) The memory maps are laid out using "unsigned long long!" types (as would > be expected). I am assuming that in a 32 bit world I can just leave these > alone- rather than convert them to unsigned long, and take the overhead or > both size and performance? Yes, they just need to be 64-bit wide. > d) Can you think of anything else I might have to change in the code? Nothing particular comes to mind... -- 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.
