On Wed, Mar 1, 2017 at 2:00 AM, Owen Waller wrote:
> Hi Dimitry,
>
> 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.
>
>
> OK that's good. As I wa
Hi Dimitry,
>
>
> 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.
>
OK that's good. As I wasn't intending to do anything apart from put in the
On Tue, Feb 28, 2017 at 2:44 AM, Owen Waller 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 ju
> > > > 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 loa
On Fri, Feb 24, 2017 at 11:24 PM, Owen Waller 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 whe
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)
On Fri, Feb 24, 2017 at 9:24 PM, Owen Waller 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 platfo
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 continuou
On Fri, Feb 24, 2017 at 2:39 PM, Owen Waller wrote:
> Hi Dimitry,
>
> C++ ThreadSanitizer works on arm64. So making it work for Go should be
> a modest amount of work.
>
>
> Thanks for confirming this. Should I now Open a issue on Github so we can
> track adding this?
If there is somebody who is
Hi Dimitry,
> > C++ ThreadSanitizer works on arm64. So making it work for Go should
be
> a modest amount of work.
Thanks for confirming this. Should I now Open a issue on Github so we
can track adding this?
Also, does it exist for any other platforms?
There are hints of PPC64. What about MIPS64?
C++ ThreadSanitizer works on arm64. So making it work for Go should be
a modest amount of work.
ThreadSanitizer does not work on any 32-bit platforms. It assumes that
it can reserve huge continuous chunks of address space for various
things.
ThreadSanitizer is not dependend on underlying hardware m
[ +dvyukov ]
On Thu, Feb 23, 2017 at 1:34 PM, Owen Waller wrote:
> Hi Ian,
>
> Go's race detector is based on and uses Thread Sanitizer, which has
> only been implemented for amd64. I'm not aware of any effort to
> extend thread sanitizer to other processors. That would have been
> done before
Hi Ian,
>
> Go's race detector is based on and uses Thread Sanitizer, which has
> only been implemented for amd64. I'm not aware of any effort to
> extend thread sanitizer to other processors. That would have been
> done before there is any likelihood of Go supporting it.
>
> Ian
Thanks for th
On Thu, Feb 23, 2017 at 9:45 AM, Owen Waller wrote:
>
> I am assuming that the race detector is not yet supported on ARM hardware.
> Having just tried to cross compile some code I am seeing:
>
> go build: -race and -msan are only supported on linux/amd64, freebsd/amd64,
> darwin/amd64 and windows/
Hi Everyone,
I am assuming that the race detector is not yet supported on ARM
hardware. Having just tried to cross compile some code I am seeing:
go build: -race and -msan are only supported on linux/amd64,
freebsd/amd64, darwin/amd64 and windows/amd64.
The 1.8 docs back this up as well.
Does a
15 matches
Mail list logo