This broke the ARM builds, because the runtime doesn't know how to unwind the kernel-supplied ...
10 years, 7 months ago
(2013-08-13 04:12:22 UTC)
#4
Message was sent while issue was closed.
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?
On Tue, Aug 13, 2013 at 8:12 AM, <rsc@golang.org> wrote: > This broke the ARM ...
10 years, 7 months ago
(2013-08-13 09:58:22 UTC)
#5
On Tue, Aug 13, 2013 at 8:12 AM, <rsc@golang.org> 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?
On Tue, Aug 13, 2013 at 5:58 AM, Dmitry Vyukov <dvyukov@google.com> wrote: > On Tue, ...
10 years, 7 months ago
(2013-08-13 18:18:43 UTC)
#6
On Tue, Aug 13, 2013 at 5:58 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Tue, Aug 13, 2013 at 8:12 AM, <rsc@golang.org> 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.
On Tue, Aug 13, 2013 at 10:18 PM, Russ Cox <rsc@golang.org> wrote: > On Tue, ...
10 years, 7 months ago
(2013-08-13 18:33:41 UTC)
#7
On Tue, Aug 13, 2013 at 10:18 PM, Russ Cox <rsc@golang.org> wrote:
> On Tue, Aug 13, 2013 at 5:58 AM, Dmitry Vyukov <dvyukov@google.com> wrote:
>
>> On Tue, Aug 13, 2013 at 8:12 AM, <rsc@golang.org> 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 :)
Issue 12717043: code review 12717043: sync/atomic: specify argsize for asm routines
(Closed)
Created 10 years, 7 months ago by dvyukov
Modified 10 years, 7 months ago
Reviewers: rsc
Base URL:
Comments: 0