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

cmd/link: order of files in archives matters on Windows #2601

Open
rsc opened this Issue Dec 21, 2011 · 13 comments

Comments

Projects
None yet
5 participants
@rsc
Contributor

rsc commented Dec 21, 2011

If you take out the special cases in src/cmd/go/build.go
that are careful to put gcc-compiled objects into the 
archive last, the misc/cgo/life example seg faults on Windows.
This suggests that something is not quite right or at least
order-dependent in the PE-processing code in src/cmd/ld.
@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Jan 20, 2012

Comment 1:

Need to revert changes to build.go from http://golang.org/cl/5504062.
Russ, what are the steps to reproduce the problem you have seen? I do not know how to
build misc/cgo/life using "go tool". Were you using windows_amd64 to test? I just fixed
bug (http://golang.org/cl/5500094) in windows_amd64 cgo were g0 stack was not
set properly. Maybe that is what you were seeing.
Alex
@rsc

This comment has been minimized.

Contributor

rsc commented Jan 20, 2012

Comment 2:

I believe that if you roll back 5504062, any test
using cgo will fail, including the one for package net.
@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Jan 20, 2012

Comment 3:

Yes it does:
--- cd ../misc/cgo/life
rm -rf *.o *.a *.[568vq] [568vq].out life *.so _obj _test _testmain.go *.exe _cgo*
test.out build.out
CGOPKGPATH= cgo --  life.go
touch _obj/_cgo_run
8g   -p life -o _go_.8  _obj/life.cgo1.go _obj/_cgo_gotypes.go
8c -FVw -I/C/MinGW/go/pkg/windows_386 -I . -o "_cgo_defun.8" _obj/_cgo_defun.c
gcc -m32 -I . -g -fPIC -O2 -o _cgo_main.o -c   _obj/_cgo_main.c
_obj/_cgo_main.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -g -fPIC -O2 -o c-life.o -c   c-life.c
c-life.c:1:0: warning: -fPIC ignored for target (all code is position independent)
gcc -m32 -I . -g -fPIC -O2 -o life.cgo2.o -c   _obj/life.cgo2.c
_obj/life.cgo2.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -I . -g -fPIC -O2 -o _cgo_export.o -c   _obj/_cgo_export.c
_obj/_cgo_export.c:1:0: warning: -fPIC ignored for target (all code is position
independent)
gcc -m32 -g -fPIC -O2 -o _cgo1_.o _cgo_main.o c-life.o life.cgo2.o _cgo_export.o
cgo -dynimport _cgo1_.o >_obj/_cgo_import.c_ && mv -f _obj/_cgo_import.c_
_obj/_cgo_import.c
8c -FVw -I . -o "_cgo_import.8" _obj/_cgo_import.c
rm -f _obj/life.a
gopack grc _obj/life.a _go_.8  _cgo_defun.8 _cgo_import.8 c-life.o  life.cgo2.o
_cgo_export.o
cp _obj/life.a "/C/MinGW/go/pkg/windows_386/life.a"
8g   main.go
8l -o life main.8
unexpected fault address 0xffffffff
throw: fault
[signal 0xc0000005 code=0x0 addr=0xffffffff pc=0x4e1594]
goroutine 1 [syscall]:
life._Cfunc_Step(0x10, 0x10)
        c:/MinGW/go/misc/cgo/life/_obj/_cgo_defun.c:45 +0x31
life.Run(0xa, 0x10, 0x10, 0x10e36000, 0x2710, ...)
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-38 +0xa3
main.main()
        c:/MinGW/go/misc/cgo/life/main.go:32 +0x128
goroutine 2 [runnable]:
life._func_001(0x10e2c0f8, 0x10e2c0f0, 0x10e2c0e8, 0x10e2c0e0, 0x10e2c0d8, ...)
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-26
created by life.GoStart
        c:/MinGW/go/misc/cgo/life/_obj/life.cgo1.go:-26 +0x17c
Thank you, Russ.
@rsc

This comment has been minimized.

Contributor

rsc commented Jan 20, 2012

Comment 4:

Unless you are hitting a bug in the current code, I am happy
to leave things as they are for now (priority-someday).
Understanding this is not terribly important.
Russ
@rsc

This comment has been minimized.

Contributor

rsc commented Jul 30, 2013

Comment 6:

Labels changed: added go1.3.

@robpike

This comment has been minimized.

Contributor

robpike commented Aug 20, 2013

Comment 7:

Labels changed: removed go1.3.

@rsc

This comment has been minimized.

Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@gopherbot

This comment has been minimized.

gopherbot commented Feb 14, 2014

Comment 9 by czarek.tomczak:

Hi, I suspect that this bug may be happening to me. Application works fine on both Linux
and OS X. But on Windows I get these "unexpected fault address 0xffffffff" errors. I'm
initializing two structures cef_app_t/cef_client_t and setting methods on them such as
"add_ref" and "release". These methods are later called by external Chromium library.
The error happens after the first call to "add_ref" made by Chromium. In import "C" the
"cef_base.h" is included
(https://github.com/CzarekTomczak/cef2go/blob/master/handlers/cef_base.h#L59) which sets
these methods.
Is there any fix for this that I could apply on my own?
@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Feb 17, 2014

Comment 10:

The "unexpected fault address 0xffffffff" error message means you are trying to access
something at address 0xffffffff. It is too general. It does not have to be related to
this issue.
Alex
@gopherbot

This comment has been minimized.

gopherbot commented Feb 17, 2014

Comment 11 by czarek.tomczak:

@comment #10 alex.bra...@gmail.com
But this same code runs perfectly fine on Linux and OS X. It is the same code for all
platforms. It happens only when calling C code from an .h file that is included using
import "C" (link in comment #9). How can I debug such error?
@alexbrainman

This comment has been minimized.

Member

alexbrainman commented Feb 18, 2014

Comment 12:

... How can I debug such error?
Give the steps to reproduce the error, I will try and look into it. I suggest you start
new issue. If we find both issues are the same, we can always merge them later.
Alex
@gopherbot

This comment has been minimized.

gopherbot commented Feb 18, 2014

Comment 13 by czarek.tomczak:

Alex, I've debugged this further. It turns out this is some problem with GCC on Windows
when calling Chromium C API, as I've prepared a C example that does same things as in Go
and these exceptions also occur. Sorry for off-topic here.
@rsc

This comment has been minimized.

Contributor

rsc commented Mar 3, 2014

Comment 14:

Adding Release=None to all Priority=Someday bugs.

Labels changed: added release-none.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015

@rsc rsc changed the title from cmd/ld: order of files in archives matters on Windows to cmd/link: order of files in archives matters on Windows Jun 8, 2015

@mvdan mvdan added the OS-Windows label Jan 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment