Hi Ted,
I don't know what's the problem with Go toolchain, maybe Ian's
hypothesis is true. But we use cross-compilation for arm64 and arm
from Debian Rodete distors and it's working. I cross-compiled executor
for arm with arm-linux-gnueabihf-gcc just few days ago. People also
recommend Linaro-prov
Streaming stacks and strings sounds fine to me. I don't see any
potential issues here.
Streaming data in real time (not waiting for an internal buffer to be
full) is somewhat more problematic, but probably doable.
Stable public format is problematic. The format proven to be unstable
over the last
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
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
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
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
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
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
I've recovered it and updated the go/benign-race link.
On Thu, 10 Feb 2022 at 18:35, Ian Lance Taylor wrote:
>
> [ + dvyukov ]
>
> On Thu, Feb 10, 2022 at 9:16 AM jake...@gmail.com wrote:
> >
> >
> > On Wednesday, February 9, 2022 at 9:14:52 AM UTC-5 peterGo wrote:
> >>
> >> Pelen Li,
> >>
> >>
Oh, sorry didn't realize this is an external thread. Here is full link:
https://docs.google.com/document/d/1WAT22FtFdMt43i3O8YrnlQTNTzZ3IoJBtu3P2DNRytg/edit?usp=sharing
> On 2/10/22, 'Dmitry Vyukov' via golang-nuts
> wrote:
> > I've recovered it and updated the
10 matches
Mail list logo
