cmd/ld: GOROOT->GOROOT_FINAL substitution fails on Windows #5458
Labels
Milestone
Comments
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 |
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. |
@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.
|
@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 |
@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). |
``` > 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. |
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. |
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 |
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. |
Update: I made it automatic. https://gist.github.com/smilekzs/5640649 |
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 |
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
|
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. |
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:
|
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
by phwhx0:
The text was updated successfully, but these errors were encountered: