Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Open
Helflym opened this issue Oct 22, 2019 · 7 comments
Open

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

Helflym opened this issue Oct 22, 2019 · 7 comments
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@Helflym
Copy link
Contributor

Helflym commented Oct 22, 2019

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:

  • Cfunc, a data symbol with a pointer to .Cfunc and a pointer to the TOC symbol (something similar to GOT stuff with ELF format)
  • .Cfunc, a text symbol which the label in .text section.

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:

  • GO asm doesn't seem able to parse this "." function.
  • Special AIX code will be needed for every programs using this stuff.

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
Copy link
Contributor

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
Copy link
Contributor Author

Helflym commented Oct 22, 2019

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
Copy link

beoran commented Oct 22, 2019

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
Copy link
Contributor

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.

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 22, 2019
@beoran
Copy link

beoran commented Oct 23, 2019

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
Copy link
Contributor

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
Copy link

beoran commented Oct 23, 2019

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

@seankhliao seankhliao changed the title cmd: calling C code without cgo on aix/ppc64 cmd/cgo: calling C code without cgo on aix/ppc64 Aug 27, 2022
@seankhliao seankhliao added this to the Unplanned milestone Aug 27, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch-ppc64x compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
6 participants
@beoran @dmitshur @ianlancetaylor @gopherbot @seankhliao @Helflym