Re: [golang-dev] ld, cgo, and stdcall imports (windows)

[minux]

On Fri, Dec 28, 2012 at 3:30 PM, james4k <ssl...@gmail.com> wrote:

For the use of stdcall functions in cgo, it seems the only part of the Go toolchain that doesn't support them yet is cmd/ld. But, it does seem to handle them mostly ok. Currently when you try to call a stdcall function from cgo, ld prints out a "not defined" message from undef() in ld/lib.c, and if I disable this, the resulting binary actually seems to run without issue, updating and drawing a working OpenGL window.

Could you please give a concrete example to show this?

cmd/ld shouldn't need to deal with any specific C calling conventions.

Anyhow, my point is that it seems as though it would not be a great deal of work to have cmd/ld recognize these stdcall imports. Is this correct? I'd like to attempt to put together a CL to address this if that is the case. Guidance/suggestions are welcome.

[james4k]

Basically the stdcall symbols in the import name table has an arg size decorator (foo@0), so when cgo loads the import symbols with debug/pe to setup the dynimports used by cmd/ld, the symbols there also have the decorators. cmd/ld will load these as symbols just fine through loaddynimports(), but then the symbol used for the external dependency for the cgo call itself does not have the stdcall decorator (is foo, should be foo@0). You are right, though, perhaps the external function symbol should be correct in the first place.

Apologies if the terminology is off; I don't have much experience with this sort of code. I will put together a basic test case as soon as I can.

[minux]

On Sat, Dec 29, 2012 at 2:34 AM, james4k <ssl...@gmail.com> wrote:

Basically the stdcall symbols in the import name table has an arg size decorator (foo@0), so when cgo loads the import symbols with debug/pe to setup the dynimports used by cmd/ld, the symbols there also have the decorators. cmd/ld will load these as symbols just fine through loaddynimports(), but then the symbol used for the external dependency for the cgo call itself does not have the stdcall decorator (is foo, should be foo@0). You are right, though, perhaps the external function symbol should be correct in the first place.

i see. I think the "#pragma dynimport" line generated by cmd/cgo should just use the

undecorated name, thus we should modify cmd/cgo instead of cmd/ld (cmd/ld doesn't

care about calling conventions or name mangling, and nor should it).

Apologies if the terminology is off; I don't have much experience with this sort of code. I will put together a basic test case as soon as I can.

thanks, please file an issue with the basic test case.

btw, you're welcomed to fix it and i'm happy to help review the CL. :)

[james4k]

Hmm yes, I believe I did try removing the decorators from the dynimport entries, but the issue then is that the import symbol would not match the export symbol in the dll you linked against. So, cmd/ld would be happy, but at runtime Windows would give a "missing entry" error. I will test this again to be sure. I agree that cmd/ld isn't at issue, and the problem lies with cgo. I'll find out more and create an issue when I'm back on a Windows machine. :)

Thanks minux!

[james4k]

Created an issue: https://code.google.com/p/go/issues/detail?id=4607

On Friday, December 28, 2012 2:12:31 PM UTC-6, minux wrote: