FAQ
Reviewers: golang-dev1,

Message:
Hello golang-dev@googlegroups.com,

I'd like you to review this change to
https://dvyukov%40google.com@code.google.com/p/go/


Description:
sync/atomic: specify argsize for asm routines
Fixes issue 6098.

Please review this at https://codereview.appspot.com/12717043/

Affected files:
    M src/pkg/sync/atomic/asm_386.s
    M src/pkg/sync/atomic/asm_amd64.s
    M src/pkg/sync/atomic/asm_arm.s
    M src/pkg/sync/atomic/asm_freebsd_arm.s
    M src/pkg/sync/atomic/asm_linux_arm.s
    M src/pkg/sync/atomic/asm_netbsd_arm.s
    M src/pkg/sync/atomic/atomic_test.go


--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Bradfitz at Aug 12, 2013 at 3:44 pm
    LGTM


    https://codereview.appspot.com/12717043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dvyukov at Aug 12, 2013 at 5:46 pm
    *** Submitted as
    https://code.google.com/p/go/source/detail?r=45d38208376a ***

    sync/atomic: specify argsize for asm routines
    Fixes issue 6098.

    R=golang-dev, bradfitz
    CC=golang-dev
    https://codereview.appspot.com/12717043


    https://codereview.appspot.com/12717043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rsc at Aug 13, 2013 at 4:12 am
    This broke the ARM builds, because the runtime doesn't know how to
    unwind the kernel-supplied atomics.

    We could update the traceback.

    Or we could access the memory before jumping to the atomic routine, so
    that the fault happens in code we control.

    Probably the traceback is a better (if uglier) approach, because it
    avoids memory traffic?


    https://codereview.appspot.com/12717043/

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Aug 13, 2013 at 9:58 am

    On Tue, Aug 13, 2013 at 8:12 AM, wrote:

    This broke the ARM builds, because the runtime doesn't know how to
    unwind the kernel-supplied atomics.

    We could update the traceback.

    Or we could access the memory before jumping to the atomic routine, so
    that the fault happens in code we control.

    Probably the traceback is a better (if uglier) approach, because it
    avoids memory traffic?

    Yes, it's better to not touch shared memory once more.

    Do you know how to fix traceback?

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Aug 13, 2013 at 6:18 pm

    On Tue, Aug 13, 2013 at 5:58 AM, Dmitry Vyukov wrote:
    On Tue, Aug 13, 2013 at 8:12 AM, wrote:

    This broke the ARM builds, because the runtime doesn't know how to
    unwind the kernel-supplied atomics.

    We could update the traceback.

    Or we could access the memory before jumping to the atomic routine, so
    that the fault happens in code we control.

    Probably the traceback is a better (if uglier) approach, because it
    avoids memory traffic?

    Yes, it's better to not touch shared memory once more.

    Do you know how to fix traceback?
    Yes, I believe that if the top-most pc is in the magic page (0xffff0000 to
    0xffff0fff) we just unwind one step (pc=lr, lr=0) before starting the
    trace. I would prefer someone else try it, though.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Aug 13, 2013 at 6:33 pm

    On Tue, Aug 13, 2013 at 10:18 PM, Russ Cox wrote:
    On Tue, Aug 13, 2013 at 5:58 AM, Dmitry Vyukov wrote:
    On Tue, Aug 13, 2013 at 8:12 AM, wrote:

    This broke the ARM builds, because the runtime doesn't know how to
    unwind the kernel-supplied atomics.

    We could update the traceback.

    Or we could access the memory before jumping to the atomic routine, so
    that the fault happens in code we control.

    Probably the traceback is a better (if uglier) approach, because it
    avoids memory traffic?

    Yes, it's better to not touch shared memory once more.

    Do you know how to fix traceback?
    Yes, I believe that if the top-most pc is in the magic page (0xffff0000 to
    0xffff0fff) we just unwind one step (pc=lr, lr=0) before starting the
    trace. I would prefer someone else try it, though.
    I've landed a workaround to fix builders (do load in our assembly):
    https://codereview.appspot.com/12869043/
    At least this crash seems to stop happening on the arm builders.
    There are lots of optimization opportunities on ARM (in particular do
    Load/Store w/o LL/SC loop), this will be another one :)

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedAug 12, '13 at 9:34a
activeAug 13, '13 at 6:33p
posts7
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase