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.

Sign up for GitHub

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: builds fail with "...ignoring symbol in section..." on s390x #20996

Closed
jcajka opened this issue Jul 13, 2017 · 8 comments
Closed

cmd/go: builds fail with "...ignoring symbol in section..." on s390x #20996

jcajka opened this issue Jul 13, 2017 · 8 comments
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.

Comments

@jcajka
Copy link
Contributor

jcajka commented Jul 13, 2017

What version of Go are you using (go version)?

Affects 1.8,1.9(beta2), devel(I would guess all versions)

What operating system and processor architecture are you using (go env)?

Fedora 27/26 on s390x

What did you do?

go build -work -a -v cmd/go

or

GOROOT_BOOTSTRAP=/path/to/existing/goroot ./make.bash

What did you expect to see?

Successful build

What did you see instead?

# cmd/go
L0�: $WORK/runtime/cgo.a(_all.o): sym#632: ignoring symbol in section 17 (type 0)
L0�: $WORK/runtime/cgo.a(_all.o): sym#633: ignoring symbol in section 17 (type 0)
L0�: $WORK/runtime/cgo.a(_all.o): sym#634: ignoring symbol in section 17 (type 0)

These symbols started to appear consistently after binutils change https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=49fced1206db40c71208c201165d65f92c69cebe on s390x. I'm still not 100% where are they actually coming from, but it seems as possible bug in parsing of elf/obj in GC, as L0� seems as really weird symbol name, but it does only appears to affect s390x, other architectures seem not to be affected. I have put in place temporal workaround in Fedora as those symbols seem to be safely ignorable.


diff --git a/src/cmd/link/internal/ld/ldelf.go b/src/cmd/link/internal/ld/ldelf.go
index d4f9fc4..87dabaa 100644
--- a/src/cmd/link/internal/ld/ldelf.go
+++ b/src/cmd/link/internal/ld/ldelf.go
@@ -799,6 +799,13 @@ func ldelf(ctxt *Link, f *bio.Reader, pkg string, length int64, pn string) {
                continue
            }

+           if sect.name == ".debug_str" && sym.name == "L0^A" && sym.type_ == 0 {
+               // introduced by https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=49fced1206db40c71208c201165d65f92c69cebe on s390x
+               // TODO investigate from where they are actually coming from, could be possible issue with elf parsing as seeing 0x1 in name is weird
+ 
+               continue
+           }
+
            if strings.HasPrefix(sym.name, ".LASF") { // gcc on s390x does this
                continue
            }
~

If you are runing older fedora you can easily reproduce by upgrading binutils to latest from rawhide dnf --releasever rawhide update binutils afterwards you should see the failures and you can easily downgrade back to original binutils version.
@sharkcz
Copy link

sharkcz commented Jul 13, 2017

https://bugzilla.redhat.com/show_bug.cgi?id=1460254 is the downstream bug with some input from our toolchain guys.

@jcajka
Copy link
Contributor Author

jcajka commented Jul 13, 2017

Based on ^^ it actually might be binutils bug.

@ALTree ALTree changed the title builds fail with "...ignoring symbol in section..." on s390x cmd/go: builds fail with "...ignoring symbol in section..." on s390x Jul 13, 2017
@ALTree
Copy link
Member

ALTree commented Jul 13, 2017 •
edited

Can we close this then? Several people on the bugzilla thread linked above seem to think that this is not a go issue.

@sharkcz
Copy link

sharkcz commented Jul 13, 2017

I would prefer to get a confirmation from the golang/s390x team that it's not doing anything unexpected.

@ALTree
Copy link
Member

ALTree commented Jul 13, 2017

cc @mundaym

@ALTree ALTree added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2017
@ianlancetaylor
Copy link
Contributor

It's clearly a bug in the GNU binutils if a symbol name with a '\001' makes it into the generated object file.

@ianlancetaylor
Copy link
Contributor

The file in question is being compiled from C code. If you run go build -x -work you will see the exact commands being used. That should let you create the file, and the commands that create it, to the binutils bug. That should let them recreate the problem without using Go.

@ALTree ALTree added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Jul 17, 2017
@gopherbot
Copy link

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@golang golang locked and limited conversation to collaborators Aug 17, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ianlancetaylor @ALTree @sharkcz @jcajka @gopherbot