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

cmd/ld: GOROOT->GOROOT_FINAL substitution fails on Windows #5458

Closed
gopherbot opened this issue May 14, 2013 · 33 comments

Comments

@gopherbot
Copy link

commented May 14, 2013

by phwhx0:

On windows platform, built go command with "go build gcflags '-N -l", then ran
it in gdb with "gdb xxx.exe", xxx here is the command name.

there is warning message showed up when gdb load the command executable as following,
warning: missing auto-load scripts referenced in section .debug_gdb_scripts of file
xxx.exe.

by using "info auto-load", it showed up that it was trying to load a python
script named
"C:/User/Admin~1/AppData/Local/Temp/2/bindist357622851/go/src/pkg/runtime/runtime-gdb.py".
There is definitely no such file at that location.

It seems that the GOROOT does not have any effect on this script auto-load.
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 14, 2013

Comment 1 by phwhx0:

forgot to mention that it is there for all version of go, even the newest one go 1.1
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 18, 2013

Comment 2 by SmileKZS:

Same here.
```
GNU gdb (GDB) 7.4
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;...
Reading symbols from D:\......../netsim.exe...done.
warning: Missing auto-load scripts referenced in section .debug_gdb_scripts
of file D:\......../netsim.exe
(gdb) info auto-load-scripts
Loaded  Script
Missing
C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go/src/pkg/runtime/runtime-gdb.py
```
Go 1.1
python26 && python27
gdb from https://code.google.com/p/go-w64
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 18, 2013

Comment 3 by SmileKZS:

I know I could just do:
```
(gdb) source ~/go/src/pkg/runtime/runtime-gdb.py
Loading Go Runtime support.
```
But it's so annoying. Can someone fix it?
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 20, 2013

Comment 4:

I have no such problem. Can you, please, provide detailed steps to reproduce the issue.
I am using gdb from http://www.equation.com/servlet/equation.cmd?fa=gdb.
Thank you.
Alex

Status changed to WaitingForReply.

@gopherbot

This comment has been minimized.

Copy link
Author

commented May 20, 2013

Comment 5 by SmileKZS:

@alex :
1. That version doesn't even load python helper.
2. Steps to reproduce: 
    1. `go build .`
    2. `gdb netsim.exe`
It seems to me that all symbol references to the runtime are (wrongly) rooted at
`C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851`.
```
GNU gdb (GDB) 7.5.50.20130118
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-w64-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>;.
This binary was built by Equation Solution <http://www.Equation.com>;...
Reading symbols from D:\........\netsim.exe...done.
(gdb) l
5      
C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go/src/pkg/runtime/rt0_windows_amd64.s:
No such file or directory.
(gdb)
```
My go installation: `go version go1.1 windows/amd64`, msi installer.
@davecheney

This comment has been minimized.

Copy link
Contributor

commented May 20, 2013

Comment 6:

@brainman I think this might be due to the OP using a binary download version of go,
which has a junk value for GOROOT embedded into it. The real issue may be that the
windows binary builds aren't properly respecting GOROOT_FINAL.
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 21, 2013

Comment 7:

@SmileKZS
I cannot reproduce it. You have to give us more details. How did you install it? Which
directory to? What is the program that you are building? Where is it stored? What are
the commands to build it? What are your environment variables are?
Step by step instructions - so we can repeat it starting from pristine Windows
installation.
@dave
Please, give me more clues. I don't see any problems here.
Thank you.
Alex
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 21, 2013

Comment 8 by SmileKZS:

@Alex
1. Official download `go1.1.windows-amd64.msi go1.1 Windows (x86 64-bit) MSI installer`
2. I installed it to `d:\usr\go`, properly setting GOROOT and GOPATH.
3. Build whatever. Hello world is fine.
4. `> go build .`
5. `> gdb xxx.exe`
6. `(gdb) l`
The point is, I'm using a BINARY distribution (instead of building it from source).
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 22, 2013

Comment 9:

SmileKZS,
Please, run these commands
go version
go env
set | find "GO"
in the same command window that you use to build your program ("go build ...") and show
us their output. Thank you.
Alex
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 22, 2013

Comment 10 by SmileKZS:

```
> go version
go version go1.1 windows/amd64
> go env
set GOARCH=amd64
set GOBIN=
set GOCHAR=6
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=d:\my\go
set GORACE=
set GOROOT=D:\usr\go
set GOTOOLDIR=D:\usr\go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-g -O2 -m64 -mthreads
set CGO_ENABLED=1
> set | find "GO"
GOARCH=amd64
GOPATH=d:\my\go
GOROOT=D:\usr\go\
```
Nothing fishy, really.
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 22, 2013

Comment 11 by SmileKZS:

@Alex
I started with NOTHING more than a clean Windows 8 installation and the MSI installer.
Could you please try the MSI installer, perhaps in a VM box?
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 22, 2013

Comment 12 by phwhx0:

Alex
FYI, what I had in details is exactly same as what @SmileKZS had provided
but on Windows 7.
Henry
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 23, 2013

Comment 13:

I can see the problem now. Thank you.
Unfortunately, I don't have quick solution yet. I can see couple problems here, but I
need more time to be clear about what they are and how to fix them.
Here https://golang.org/issue/5533 is one of related issues, if you
want to track it. But, I believe, there are more.
Meantime, you could use "set substitute-path
C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go D:/usr/go" gdb command to
point to the source files.
Alex

Owner changed to @alexbrainman.

Status changed to Accepted.

@gopherbot

This comment has been minimized.

Copy link
Author

commented May 23, 2013

Comment 14 by phwhx0:

it seems that the 'set substitute-path' suggested by Alex does not work for this case
from my trying. Anyone else?
Henry
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 24, 2013

Comment 15:

Henry,
The command I provided should work for SmileKZS, because it includes his installation
path. Your installation path, I expect, will be different. So you need to change the
command accordingly. You should run "go env" command and look for
"GOROOT=<YOUR_GOROOT>" variable. Then just do:
set substitute-path C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go
<YOUR_GOROOT>
in gdb (replace <YOUR_GOROOT> with whatever your "go env" shows.
Alex
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 24, 2013

Comment 16 by SmileKZS:

Alex,
Instead of using gdb command, I created a symlink at the fake path and it's apparently
working now. Script and source of runtime all load now.
FYI, the command:
```
c:
cd \
mkdir \Users\ADMINI~1\AppData\Local\Temp\2\bindist357622851
cd \Users\ADMINI~1\AppData\Local\Temp\2\bindist357622851
mklink /J go %GOROOT%
```
And it might be a good idea to insert this into the installer as a workaround.
---
However the script itself seem to have (the same) problems on both of my windows boxes.
I'll play more with it and maybe open another issue.
@gopherbot

This comment has been minimized.

Copy link
Author

commented May 24, 2013

Comment 17 by SmileKZS:

Update: I made it automatic.
https://gist.github.com/smilekzs/5640649
@alexbrainman

This comment has been minimized.

Copy link
Member

commented May 24, 2013

Comment 18:

Glad it helps, SmileKZS. I don't like workarounds. We should fix it instead.
Alex
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 30, 2013

Comment 19:

Labels changed: added priority-later, go1.2, removed priority-triage.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Jul 31, 2013

Comment 20:

rsc,
There are 2 problems here:
1) when building binary windows distro, we have
C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist357622851/go instead of c:\go written into
all lib files - this is because GOROOT -> GOROOT_FINAL substitution logic does not work
for windows paths in [568][acg];
2) dwarf source paths cannot be used if windows binary distro is installed anywhere but
c:\go - I reported it separately  https://golang.org/issue/5533
Perhaps we should create a new issue for 1) and close this one. Or change this issue
subject to 1). Pick what you like.
Alex
@rsc

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2013

Comment 21:

Okay, then let's leave this for Go 1.3, which will have plenty of other linker changes.

Labels changed: added go1.3, removed go1.2.

@robpike

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2013

Comment 22:

Labels changed: removed go1.3.

@alexbrainman

This comment has been minimized.

Copy link
Member

commented Aug 21, 2013

Comment 23:

I think this needs to be fixed. This affects binary distribution, and, I suspect, most
windows users go for that option. Everything that uses symbol paths is broken on binary
distro. For example, (using go version go1.1.2 windows/386) this simple program
package main
import (
    "net/http"
)
func handler(w http.ResponseWriter, r *http.Request) {
    panic("A")
}
func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}
prints this stack trace
C:\go\path\mine\src\t>go run main.go
2013/08/21 16:03:46 http: panic serving 127.0.0.1:4668: A
goroutine 5 [running]:
net/http.func·007()
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1022 +0x9e
main.handler(0x110403a0, 0x110154c0, 0x1101c620)
        C:/go/path/mine/src/t/main.go:10 +0x10f
net/http.HandlerFunc.ServeHTTP(0x5cd9b4, 0x110403a0, 0x110154c0, 0x1101c620)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1149 +0x3b
net/http.(*ServeMux).ServeHTTP(0x11025b40, 0x110403a0, 0x110154c0, 0x1101c620)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1416 +0xdc
net/http.serverHandler.ServeHTTP(0x11016420, 0x110403a0, 0x110154c0, 0x1101c620)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1517 +0x120
net/http.(*conn).serve(0x110182d0)
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1096 +0x652
created by net/http.(*Server).Serve
        C:/Users/ADMINI~1/AppData/Local/Temp/2/bindist465310315/go/src/pkg/net/http/server.go:1564 +0x241
exit status 2
As you can see, all stdlib paths are as they where when Andrew built the distro - all
refer to his tmp directory. It looks silly.
Russ was going to fix this for 1.3. But I think we should fix it for 1.2 instead. I am
happy to do it. The only concern I have is there many places:
# pwd
/root/go/root/src/cmd
# grep 'static.*goroot_final' * -r
5a/lex.c:       static char *goroot, *goroot_final;
5c/swt.c:       static char *goroot, *goroot_final;
6a/lex.c:       static char *goroot, *goroot_final;
6c/swt.c:       static char *goroot, *goroot_final;
8a/lex.c:       static char *goroot, *goroot_final;
8c/swt.c:       static char *goroot, *goroot_final;
gc/obj.c:       static char *goroot, *goroot_final;
that code needs to change. If I write a common function that does rewriting, is there a
way to share that function between different commands? Where does such shared code lives?
Rob, you removed Go1.3 label of this issue. Why?
Alex
@rsc

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2013

Comment 24:

Labels changed: added go1.3.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 25:

Labels changed: added release-go1.3.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 26:

Labels changed: removed go1.3.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2013

Comment 27:

Labels changed: added repo-main.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2014

Comment 29:

Alex, I wrote a common function that does the rewriting. It is at the bottom of
linkgetline in src/liblink/obj.c. Can you please check and see whether the GOROOT_FINAL
substitution is working correctly on Windows for you? (This is in CL 88300045, which I
just submitted.)
My guess is that we are building the distribution in some directory X and getcwd is
returning X1 but GOROOT is set to X2. For exmaple getcwd might return c:\progra~1\go and
GOROOT might be set to c:\program files\go. In this case the paths beginning
c:\progra~1\go will not be recognized as beginning with GOROOT. The solution would
probably be not to set GOROOT at all explicitly during distribution, because then
cmd/dist will use getcwd to set it, and hopefully it will match what getcwd in the
compilers sees.
Another possibility is that GOROOT was set to c:\tmp\go but the file path was c:/tmp/go,
and so the code did not think the file path began with GOROOT. In my new code
backslashes and slashes are treated as equivalent, as are upper-vs-lower case letters,
so hopefully those kinds of different spellings won't be an issue anymore. If that was
the problem with Andrew's distribution, then maybe it is already fixed. If the problem
is an 8.3 name vs a long name that's a little trickier.
@rsc

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2014

Comment 30:

I'm going to mark this as not blocking the Go 1.3 beta, but I would still like to see
this fixed for the Go 1.3 release if possible.
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Apr 16, 2014

Comment 32:

rsc, I will test your change and let you know. Thank you.
Alex
@alexbrainman

This comment has been minimized.

Copy link
Member

commented Apr 16, 2014

Comment 33:

Fixed by https://golang.org/cl/88300045
I have tested it with a little test (see attached a.diff) I wrote a while ago. The
TestALEX PASSes.
Alex

Status changed to Fixed.

Attachments:

  1. a.diff (3528 bytes)
@gopherbot

This comment has been minimized.

Copy link
Author

commented Jul 28, 2014

Comment 34 by simonritchie.uk:

I had similar problems to the issue reported here, despite it being fixed months ago. 
It appears that simply upgrading to a fixed version of Go doesn't clear it, because the
damage is already done.  I had to uninstall GO, reinstall the latest version, rename my
GOCODE directory, create a new one and download all the packages that I depend on all
over again.  Then I copied my source code from my backup and recompiled it.  Everything
then worked OK.
Simon
@davecheney

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2014

Comment 35:

@simon, after upgrading Go it should have been sufficient to remove your $GOCODE/pkg
folder.
Please open a new issue if this is still a problem for you.
@rsc rsc added this to the Go1.3 milestone Apr 14, 2015
@rsc rsc removed the release-go1.3 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.