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

Jump to bottom

cmd/go: TestScript/version failing on Plan 9 #31706

Closed
0intro opened this issue Apr 26, 2019 · 4 comments
Closed

cmd/go: TestScript/version failing on Plan 9 #31706

0intro opened this issue Apr 26, 2019 · 4 comments
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Plan9 Testing An issue that has been verified to require only test changes, not just a test failure.
Milestone
Unplanned

Comments

@0intro
Copy link
Member

0intro commented Apr 26, 2019 •
edited

CL 173343 implemented go version <binary>. However, the openExe function doesn't implement decoding of Plan 9 executables. Consequently, the TestScript/version test fails.

--- FAIL: TestScript (0.01s)
    --- FAIL: TestScript/version (1.84s)
        script_test.go:190: 
            > env GO111MODULE=on
            > go build -o fortune.exe rsc.io/fortune
            [stderr]
            go: finding rsc.io/fortune v1.0.0
            go: downloading rsc.io/fortune v1.0.0
            go: extracting rsc.io/fortune v1.0.0
            go: finding rsc.io/quote v1.5.2
            go: downloading rsc.io/quote v1.5.2
            go: extracting rsc.io/quote v1.5.2
            go: finding rsc.io/sampler v1.3.0
            go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            go: downloading rsc.io/sampler v1.3.0
            go: extracting rsc.io/sampler v1.3.0
            go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            > go version fortune.exe
            [stderr]
            fortune.exe: unrecognized executable format
            > stdout '^fortune.exe: .+'
            FAIL: testdata/script/version.txt:4: no match for `(?m)^fortune.exe: .+` found in stdout
@0intro 0intro self-assigned this Apr 26, 2019
@0intro
Copy link
Member Author

0intro commented Apr 27, 2019

I've started to implement parsing of Go version in Plan 9 a.out executables.

I can match the info magic \xff Go buildinf: and parse endianess and ptrSize successfully.
However, I fail at reading values of buildVersion and modinfo.

% go test -v -run 'TestScript/^version$'
=== RUN   TestScript
=== RUN   TestScript/version
=== PAUSE TestScript/version
=== CONT  TestScript/version
go test proxy starting
go proxy_test: invalid module path encoding "example.com/invalidpath/v1": malformed module path "example.com/invalidpath/v1": invalid version
go test proxy running at GOPROXY=http://127.0.0.1:43806/mod
--- FAIL: TestScript (0.00s)
    --- FAIL: TestScript/version (2.15s)
        script_test.go:190: 
            WORK=$WORK
            PATH=/tmp/cmd-go-test-102488855/tmpdir217311114/testbin
            home=/no-home
            CCACHE_DISABLE=1
            GOARCH=386
            GOCACHE=/usr/djc/lib/cache/go-build
            GOOS=plan9
            GOPATH=$WORK/gopath
            GOPROXY=http://127.0.0.1:43806/mod
            GOROOT=/usr/go
            GONOVERIFY=*
            TMPDIR=$WORK/tmp
            devnull=/dev/null
            goversion=1.13
            :=
            path=/tmp/cmd-go-test-102488855/tmpdir217311114/testbin/bin.
            exe=
            CC=8c
            GCCGO=gccgo
            
            > env GO111MODULE=on
            > go build -o fortune.exe rsc.io/fortune
            [stderr]
            go: finding rsc.io/fortune v1.0.0
            go: downloading rsc.io/fortune v1.0.0
            go: extracting rsc.io/fortune v1.0.0
            go: finding rsc.io/quote v1.5.2
            go: downloading rsc.io/quote v1.5.2
            go: extracting rsc.io/quote v1.5.2
            go: finding rsc.io/sampler v1.3.0
            go: finding golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            go: downloading rsc.io/sampler v1.3.0
            go: extracting rsc.io/sampler v1.3.0
            go: downloading golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            go: extracting golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c
            > go version fortune.exe
            [stdout]
            Header Bss 0x00014060
            Header Entry 0x00043820
            Header PtrSize 4
            Header LoadAddress 0x00001000
            Header HdrSize 32
            Section text 0x00000020 743971
            Section data 0x000b5a43 58560
            Section syms 0x000c3f03 64855
            Section spsz 0x000d3c5a 0
            Section pcsz 0x000d3c5a 0
            ReadData 0x000b5a43 65536
            match Go buildinf
            LittleEndian
            ptrSize 4
            ReadData 0x000c2b68 8
            ReadData 0x00000000 0
            vers ''
            ReadData 0x000c2b88 8
            ReadData 0x00000000 0
            mod ''
            [stderr]
            fortune.exe: go version not found
            > stdout '^fortune.exe: .+'
            FAIL: testdata/script/version.txt:4: no match for `(?m)^fortune.exe: .+` found in stdout
            
FAIL
exit status: 'go.test 547205: 1'
FAIL	cmd/go	8.536s

The buildVersion and modinfo addresses I get are identical to the values returned by the nm tool.

% nm fortune.exe | grep '(buildVersion|modinfo)'
   c2b68 D runtime.buildVersion
   c2b88 D runtime.modinfo

Either the buildVersion and modinfo values aren't set correctly or I did a mistake in the addresses calculations when reading the values.

@rsc In Plan 9 executables, data segment addresses are absolute to the beginning of the file, right?

@gopherbot
Copy link

Change https://golang.org/cl/174201 mentions this issue: cmd/go: implement parsing of Go version in Plan 9 binaries

@bcmills bcmills added NeedsFix The path to resolution is known, but the work has not been done. Testing An issue that has been verified to require only test changes, not just a test failure. labels May 7, 2019
@bcmills bcmills added this to the Unplanned milestone May 7, 2019
@rsc
Copy link
Contributor

rsc commented May 9, 2019

@rsc In Plan 9 executables, data segment addresses are absolute to the beginning of the file, right?

No. See http://man.cat-v.org/plan_9/6/a.out. There's a zeroed page at the start of the addr space to catch nil writes, and then some extra page alignment between text and data.

@rsc rsc unassigned 0intro Jun 23, 2022
@rsc rsc mentioned this issue Mar 15, 2023
Closed
@oridb
Copy link
Contributor

oridb commented Mar 15, 2023

I believe this is obsolete; I think I fixed this in 0816d38

@bcmills bcmills closed this as completed Mar 16, 2023
@golang golang locked and limited conversation to collaborators Mar 15, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsFix The path to resolution is known, but the work has not been done. OS-Plan9 Testing An issue that has been verified to require only test changes, not just a test failure.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @bcmills @oridb @0intro @gopherbot