[go-nuts] Re: Calling a Go function from asm ("fatal error: missing stackmap")

2016-09-19 Thread Peng Gao


On Tuesday, September 20, 2016 at 11:00:34 AM UTC+8, Peng Gao wrote:
>
> BTW in your test file, you can directly append your bytes slice.
> b1 = append(b1, vs...)
> and slicesEqual is redundant, bytes.Equal does test the length of two 
> arguments
>
I mix up cap and len, just ignore it. 

>
> On Tuesday, September 20, 2016 at 6:56:55 AM UTC+8, Caleb Spare wrote:
>>
>> I'm trying to call a Go function from asm and I'm having trouble figuring 
>> out the details.
>>
>> (In the past I've always endeavored to avoid this situation and make all 
>> my asm functions be leaf functions, but in my current use case it would be 
>> most helpful to be able to call a Go helper.)
>>
>> See the demo code at 
>> https://github.com/cespare/misc/tree/master/asm/stackmap or go get 
>> github.com/cespare/misc/asm/stackmap.
>>
>> For 
>> ​the​
>>  demo, I have a small function with an append-style API:
>>
>> func X(b []byte) []byte
>>
>> This calls a Go helper growSlice.
>>
>> This code sometimes works, but if I run `go test -count 1000` I'll 
>> quickly see
>>
>> runtime: frame github.com/cespare/misc/asm/stackmap.X untyped locals 
>> 0xc420042bf8+0x30
>> fatal error: missing stackmap
>> ...
>>
>> I've read through the Runtime Coordination section of the 
>> ​asm
>>  walkthrough (https://golang.org/doc/asm#runtime) several times, but I 
>> don't see the problem.
>>
>> Here is my understanding of a few relevant bits of that section (which 
>> might be incorrect):
>>
>> If the results will hold live pointers during a call instruction, the 
>>> function should start by zeroing the results and then executing the 
>>> pseudo-instruction GO_RESULTS_INITIALIZED.
>>
>>
>> This doesn't seem to apply to my code because the results aren't 
>> populated until after the CALL.
>>
>> If a function has no local stack frame, the pointer information can be 
>>> omitted. This is indicated by a local frame size annotation of $0-n on the 
>>> TEXT instruction. The pointer information can also be omitted if the 
>>> function contains no call instructions. Otherwise, the local stack frame 
>>> must not contain pointers, and the assembly must confirm this fact by 
>>> executing the pseudo-instruction NO_LOCAL_POINTERS.
>>
>>
>> ​My function makes a CALL with arguments. But it has to ​have a pointer 
>> (the slice) on the local stack frame in order to pass to that helper. I 
>> don't really understand what this section means.
>>
>> `go vet` doesn't say anything about my code.
>>
>> Any ideas?
>>
>> Thanks!
>> Caleb
>>
>

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


[go-nuts] Re: Calling a Go function from asm ("fatal error: missing stackmap")

2016-09-19 Thread Peng Gao
BTW in your test file, you can directly append your bytes slice.
b1 = append(b1, vs...)
and slicesEqual is redundant, bytes.Equal does test the length of two 
arguments.


On Tuesday, September 20, 2016 at 6:56:55 AM UTC+8, Caleb Spare wrote:
>
> I'm trying to call a Go function from asm and I'm having trouble figuring 
> out the details.
>
> (In the past I've always endeavored to avoid this situation and make all 
> my asm functions be leaf functions, but in my current use case it would be 
> most helpful to be able to call a Go helper.)
>
> See the demo code at 
> https://github.com/cespare/misc/tree/master/asm/stackmap or go get 
> github.com/cespare/misc/asm/stackmap.
>
> For 
> ​the​
>  demo, I have a small function with an append-style API:
>
> func X(b []byte) []byte
>
> This calls a Go helper growSlice.
>
> This code sometimes works, but if I run `go test -count 1000` I'll quickly 
> see
>
> runtime: frame github.com/cespare/misc/asm/stackmap.X untyped locals 
> 0xc420042bf8+0x30
> fatal error: missing stackmap
> ...
>
> I've read through the Runtime Coordination section of the 
> ​asm
>  walkthrough (https://golang.org/doc/asm#runtime) several times, but I 
> don't see the problem.
>
> Here is my understanding of a few relevant bits of that section (which 
> might be incorrect):
>
> If the results will hold live pointers during a call instruction, the 
>> function should start by zeroing the results and then executing the 
>> pseudo-instruction GO_RESULTS_INITIALIZED.
>
>
> This doesn't seem to apply to my code because the results aren't populated 
> until after the CALL.
>
> If a function has no local stack frame, the pointer information can be 
>> omitted. This is indicated by a local frame size annotation of $0-n on the 
>> TEXT instruction. The pointer information can also be omitted if the 
>> function contains no call instructions. Otherwise, the local stack frame 
>> must not contain pointers, and the assembly must confirm this fact by 
>> executing the pseudo-instruction NO_LOCAL_POINTERS.
>
>
> ​My function makes a CALL with arguments. But it has to ​have a pointer 
> (the slice) on the local stack frame in order to pass to that helper. I 
> don't really understand what this section means.
>
> `go vet` doesn't say anything about my code.
>
> Any ideas?
>
> Thanks!
> Caleb
>

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