search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
124.11k stars 17.68k forks source link

cmd/cgo: calling C code without cgo on aix/ppc64 #35071

Open Helflym opened 5 years ago

Helflym commented 5 years ago

In CL 198798, @jpap allows Go asm to call/jump directly to a C function defined in a .syso files. The jump is performed like this JMP Cfunc(SB). However, on AIX, this JMP doesn't work. A C function has two symbols:

Therefore, JMP Cfunc(SB) is jumping to a data symbol which obviously doesn't work. The normal 'AIX' code should be JMP .Cfunc(SB). However, there are several problems with that:

What's the policy of Go in this case ? Do we want to match C code (ie using JMP .Cfunc(SB)) or do we want to be closer to Go code (ie using JMP Cfunc(SB)) and afterwards changing ASM generated in cmd/internal.

Note that both solution might be added. So people might want to write special ASM code for AIX with "dot" function, etc. While others just want their code to work in all platforms.

ianlancetaylor commented 5 years ago

This kind of code is inevitably highly system dependent. I think it's OK to skip the test on AIX and worry about the case if it actually comes up. If we understand what people want to do on AIX we might have a clearer understanding of how we should handle it.

Helflym commented 5 years ago

The test is actually working because it's only checking the compilation. The program made isn't run. So nothing to do at the moment.

beoran commented 5 years ago

By the way, it would be nice if this also worked on Linux for .so files. CGo is bothersome and has quite a performance overhead. Go can already call functions in shared libaries on some platforms, I think it should be able to do so on all platforms. Look at nocgo for a hack that enables this on Linux: https://github.com/notti/nocgo

ianlancetaylor commented 5 years ago

Calling functions directly without using cgo is very error prone. If the C function blocks for any reason that can cause the entire program to hang. I do not think it is a good idea to make it easy. It would just make it very easy for people to shoot themselves in the foot.

beoran commented 5 years ago

I know the dangers very well, and I am not saying it should be easy, just that it should be possible using the Go standard library. Much like the unsafe package, this would be used for low level programming.

Already, the Windows port, and the OSX port call functions in shared libraries in stead of direct system calls, because on those OS, the kernel has no stable ABI. Fortunately, the Linux kernel is sane and does have a stable ABI. However, but in the context of graphical and GUI applications, in particular Mesa and Gallium, unfortunately, most functionality is not implemented in the kernel but in shared C libraries, which, since they are driver specific, must be loaded at run time. In such situations, CGo provides a less than ideal experience, and the ability to call C functions directly from a DLL would be much appreciated.

ianlancetaylor commented 5 years ago

We have that ability. It's just hard to use.

In any case, this discussion is misplaced on this issue. Please open a new issue if you want to make a proposal. Thanks.

beoran commented 5 years ago

OK, I agree that this is misplaced. I will probably open a new issue on this topic once I collect my arguments better.