On Mon, Aug 29, 2016 at 8:19 AM, wrote:
>> I'm only talking about changing Darwin.
>
>
> Sorry, I meant pushing the gcc callee-saved registers in the assembly
> sigtramp functions (for example in sys_darwin_amd64.s) as it is done in
> crosscall2. I ran into the issue, that the content in the rbx
>
> I'm only talking about changing Darwin.
>
Sorry, I meant pushing the gcc callee-saved registers in the assembly
sigtramp functions (for example in sys_darwin_amd64.s) as it is done in
crosscall2. I ran into the issue, that the content in the rbx register was
overwritten by the sigfwdgo()
On Mon, Aug 29, 2016 at 12:18 AM, wrote:
>> OK, then perhaps we need setsig in os_darwin.go to set
>> the sigaction field to a new function, written in assembler, like
>> sigtramp, but taking just the sigaction arguments.
>
>
> Could you please explain, why it is necessary to use sa_tramp with a
>
> OK, then perhaps we need setsig in os_darwin.go to set
> the sigaction field to a new function, written in assembler, like
> sigtramp, but taking just the sigaction arguments.
Could you please explain, why it is necessary to use sa_tramp with a custom
function instead of using the defau
On Fri, Aug 26, 2016 at 7:36 AM, wrote:
>> Interesting. Maybe we need to change this line in setsig in
>> runtime/os_darwin.go
>> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) = fn
>> to be
>> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) =
>> unsafe.Pointer(funcPC(sigtramp))
>
>
> Tha
>
> Interesting. Maybe we need to change this line in setsig in
> runtime/os_darwin.go
> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) = fn
> to be
> *(*uintptr)(unsafe.Pointer(&sa.__sigaction_u)) =
> unsafe.Pointer(funcPC(sigtramp))
>
That's not possible, the signatures of sa_tr
On Fri, Aug 26, 2016 at 6:35 AM, wrote:
>
> The reason for the morestack call is, that sigtramp is not called in my code
> example. The sa_tramp seems to be overwritten in my call to
> sigaction(int,struct sigaction*,struct sigaction*) and I cannot retrieve the
> original trampoline function via
Hi,
It took a while to understand what's going on.
> I'm not sure which part of the os/signal docs you are thinking of.
I'm referring to "Go programs that use cgo or SWIG", last paragraph ("If
the Go signal handler is invoked on a non-Go thread not running Go code
[...]"). I couldn't get a
On Fri, Aug 19, 2016 at 2:33 AM, wrote:
>> It appears as though the signal handler is somehow not running on the
>> alternate signal stack. I don't know why that would be, though. I
>> have no other explanation. You'll have to debug it.
>>
> I can see by the stack pointers, that the alt stack is
>
> It appears as though the signal handler is somehow not running on the
> alternate signal stack. I don't know why that would be, though. I
> have no other explanation. You'll have to debug it.
>
> I can see by the stack pointers, that the alt stack is used on both, Linux
and Darwin. But I'm
On Thu, Aug 18, 2016 at 6:56 AM, wrote:
>
> i'm trying to replace a Go signal handler by a C signal handler and try to
> call the stored Go handler inside that C handler. It works well on Linux,
> but on Darwin I receive a "runtime: split stack overflow" exception. Is that
> supposed to work on O
11 matches
Mail list logo
