May want to check out this setting on your issue: "cmd/internal/obj: reject splittable ABIInternal functions without morestack spill info (e.g., asm functions) because we can't generate a correct morestack path " Unless of course you don't want to use asm functions On Thursday, March 25, 2021 at 8:03:42 PM UTC-7 Marco Ronchese wrote:
> Thanks for the explanation. > > I did some reading and I see there is some work going to switch to > register-based calling convention ( > https://github.com/golang/go/issues/40724). > This could be a good occasion to try to fix this. In that issue is > discussed which kind of SysCallbacks are needed, I will drop a comment and > see what happens from there. > > > On Thursday, 25 March 2021 at 20:46:06 UTC+1 Ian Lance Taylor wrote: > >> On Thu, Mar 25, 2021 at 11:38 AM Marco Ronchese <marcor...@gmail.com> >> wrote: >> > >> > I am calling certain Windows API from Go code (without CGO), everything >> works flawlessly, but now I bumped into this issue. >> > >> > I want to register a callback that accepts (also) a float as argument ( >> https://docs.microsoft.com/en-us/windows/win32/api/audiopolicy/nf-audiopolicy-iaudiosessionevents-onsimplevolumechanged) >> >> and I get a runtime error: >> > >> > panic: compileCallback: float arguments not supported >> > >> > This panic is thrown at >> https://golang.org/src/runtime/syscall_windows.go#L125 >> > >> > I tried to receive an uint32 and convert it with math.Float64frombits >> (well, basically just with some pointer arithmetic) but no luck. >> > >> > This issue on Github (https://github.com/golang/go/issues/6510), which >> got fixed, is related, but there the syscall itself was returning floats, >> here is a callback to register with a syscall. >> > >> > The questions are: >> > 1) Can I work around this with some clever pointer conversion? From >> what I understand this is not the case since basically Go runtime is >> ignoring some CPU registers where that value is stored, am I right? >> > 2) What is the philosophy behind the choice of not supporting this kind >> of stuff? Is something like: "Go runtime needs to support the basic syscall >> the language, its standard library and most users need, and for the rest C >> is the way" >> > >> > A while back I though using CGO for these kind of stuff was the only >> way, few weeks ago I discover that this was not necessarily the case. I was >> thrilled I could write everything in Go, but maybe this is not true after >> all. Well, quite a journey. Of course I hope I am wrong >> >> The problem is the calling convention. syscall.NewCallback has to >> take the C values, which arrive using the C calling convention, and >> pass them to Go using the Go calling convention. On amd64 the main >> step here is callbackasm1 in runtime/sys_windows_amd64.s That >> function takes the C argument registers and stores them in the right >> place for the Go code. Unfortunately, on x86 floats are passed in >> floating point registers, not the ordinary argument registers. So to >> handle floating point arguments the code would need to get them from >> the right register. >> >> Not supporting this case is not a philosophical issue. It's that >> nobody really knows how to implement it. >> >> Ian >> > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6f52c808-81e4-495b-bfcd-2fb582244933n%40googlegroups.com.
