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/dist: goc2c ignores GOROOT_FINAL #8524

Closed
gopherbot opened this issue Aug 13, 2014 · 5 comments
Closed

cmd/dist: goc2c ignores GOROOT_FINAL #8524

gopherbot opened this issue Aug 13, 2014 · 5 comments
Milestone

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Aug 13, 2014

by henning@schmiedehausen.org:

When building golang, the environment variable GOROOT_FINAL can be set to indicate a
different installation location from the build location. This works fine, except that
the goc2c build step embeds line numbers in the resulting c source files that refer to
the build location, no the install location:

// auto generated by go tool dist
// goos=linux goarch=amd64


#include "runtime.h"
#include "type.h"
#include "../../cmd/ld/textflag.h"
#define M0 (sizeof(uintptr)==4 ? 2860486313UL : 33054211828000289ULL)
#define M1 (sizeof(uintptr)==4 ? 3267000013UL : 23344194077549503ULL)

#line 13 "/home/hschmiedehausen/rpmbuild/BUILD/go/src/pkg/runtime/alg.goc"

This is the start of zalg_linux_amd64.c The path
"/home/hschmiedehausen/rpmbuild/BUILD/go" is the build location of the tree,
not the install location.

This would not be a big deal, except that in turn the linker uses the location of
runtime/string.goc to embed the gdb script in the resulting binary:

readelf -p41  ~/code/docker/bundles/1.1.3-dev/dynbinary/docker

String dump of section '.debug_gdb_scripts':
  [     1]  /home/hschmiedehausen/rpmbuild/BUILD/go/src/pkg/runtime/runtime-gdb.py

and as a net result, the debugger now complains that the script is outside its load path
(it has the install location configured).

With the attached patch and GOROOT_FINAL set to the install location, the generated
sources look like this:

// auto generated by go tool dist
// goos=linux goarch=amd64


#include "runtime.h"
#include "type.h"
#include "../../cmd/ld/textflag.h"
#define M0 (sizeof(uintptr)==4 ? 2860486313UL : 33054211828000289ULL)
#define M1 (sizeof(uintptr)==4 ? 3267000013UL : 23344194077549503ULL)

#line 13 "/usr/lib/golang/src/pkg/runtime/alg.goc"
...

So the #line references use the correct installation path.

And the resulting binaries contain the correct script:

readelf -p41  ~/code/docker/bundles/1.1.3-dev/dynbinary/docker

String dump of section '.debug_gdb_scripts':
  [     1]  /usr/lib/golang/src/pkg/runtime/runtime-gdb.py

and the debugger is happy.

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

What does 'go version' print?
go version go1.3 linux/amd64

What steps reproduce the problem?
If possible, include a link to a program on play.golang.org.

1. Build the golang from source with a different install location from the build
location (GOROOT != GOROOT_FINAL)
2. look at the output of e.g. go/src/pkg/zalg_*.c
3. verify that the #line statements contain the build, not the install location. 

What happened?

Build a binary (I used docker). Use the readelf program (on linux) to dump the
.debug_gdb_scripts section. It contains the build location for the script, not the
install location.

What should have happened instead?

The generated source files should contain the install location. The resulting
.debug_gdb_scripts section should contain the install location.


Please provide any additional information below.

Repeat the steps with the attached path. Now the information is correct. And I can debug
with my RPM installed golang on Fedora. ;-)

Attachments:

  1. go-1.3-goc2c.patch (2126 bytes)
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 13, 2014

Comment 1:

Can you send the patch using the process described at
http://golang.org/doc/contribute.html ?  Thanks.

Status changed to Accepted.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 13, 2014

Comment 2:

Labels changed: added repo-main, release-go1.4.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Aug 14, 2014

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Aug 14, 2014

Comment 4:

CL https://golang.org/cl/128230046 mentions this issue.
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Aug 15, 2014

Comment 5:

This issue was closed by revision 7eba885.

Status changed to Fixed.

@rsc rsc added this to the Go1.4 milestone Apr 14, 2015
@rsc rsc removed the release-go1.4 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 25, 2016
wheatman added a commit to wheatman/go-akaros that referenced this issue Jun 25, 2018
When building golang, the environment variable GOROOT_FINAL can be set
to indicate a different installation location from the build
location. This works fine, except that the goc2c build step embeds
line numbers in the resulting c source files that refer to the build
location, no the install location.

This would not be a big deal, except that in turn the linker uses the
location of runtime/string.goc to embed the gdb script in the
resulting binary and as a net result, the debugger now complains that
the script is outside its load path (it has the install location
configured).

See https://code.google.com/p/go/issues/detail?id=8524 for the full
description.

Fixes golang#8524.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/128230046
wheatman added a commit to wheatman/go-akaros that referenced this issue Jul 9, 2018
When building golang, the environment variable GOROOT_FINAL can be set
to indicate a different installation location from the build
location. This works fine, except that the goc2c build step embeds
line numbers in the resulting c source files that refer to the build
location, no the install location.

This would not be a big deal, except that in turn the linker uses the
location of runtime/string.goc to embed the gdb script in the
resulting binary and as a net result, the debugger now complains that
the script is outside its load path (it has the install location
configured).

See https://code.google.com/p/go/issues/detail?id=8524 for the full
description.

Fixes golang#8524.

LGTM=iant
R=golang-codereviews, iant
CC=golang-codereviews
https://golang.org/cl/128230046
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.