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

debug/gosym: TestPCLine failing on Plan 9 #14536

Closed
0intro opened this issue Feb 26, 2016 · 4 comments
Closed

debug/gosym: TestPCLine failing on Plan 9 #14536

0intro opened this issue Feb 26, 2016 · 4 comments

Comments

@0intro
Copy link
Member

0intro commented Feb 26, 2016

The TestPCLine test is failing on Plan 9:

entry not text: main
--- FAIL: TestPCLine (0.17s)
    pclntab_test.go:50: exit status: 'go 149759: 1'
FAIL
FAIL    debug/gosym 0.174s

This failure can only be seen on the plan9/amd64 builder, because this test is only enabled on amd64.

The test runs the following commands:

% go tool asm -o /tmp/pclinetest.o pclinetest.asm
% go tool link -H linux -E main -o /tmp/pclinetest /tmp/pclinetest.o
entry not text: main

The Entryvalue function return "entry not text: main", because s.Type is type SXREF instead of STEXT.

In fact, in the libinit function, INITENTRY was set to type SXREF because DynlinkingGo() returns false on Plan 9.

@0intro 0intro self-assigned this Feb 26, 2016
@ianlancetaylor
Copy link
Contributor

DynlinkingGo normally returns false on GNU/Linux too. I think there must be some other aspect to this.

@ianlancetaylor
Copy link
Contributor

This is working on GNU/Linux because the linker is being invoked with -E main, and runtime/rt0_linux_amd64.s defines a symbol main, thus ensuring that the INITENTRY symbol gets to be STEXT. plan9 doesn't define main, so the symbol remains SXREF, and the linker balks.

I don't know why the test is passing a -E option; it might work fine if it simply didn't do that. The -E option dates back to revision f277ebf in September, 2009, and has simply been carried forward since then.

@0intro
Copy link
Member Author

0intro commented Feb 26, 2016

Yes, you're right. I propose CL 19973 instead.

@gopherbot
Copy link

CL https://golang.org/cl/19973 mentions this issue.

@golang golang locked and limited conversation to collaborators Feb 28, 2017
@rsc rsc unassigned 0intro Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants