-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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/link: unexpectedly long symbol name #15104
Comments
I would love to see that symbol name. (It's a bug because big data should be SHAed into the name.) Given that with position-independent code we have to keep a lot of symbol names around, I've been meaning to survey them, just haven't got there yet. |
Unfortunately I can't reproduce. /cc @mpvl |
Oh, I have to |
The symbol name is 6K: 2016/04/04 15:48:29 $WORK/golang.org/x/text/unicode/cldr/_test/golang.org/x/text/unicode/cldr.a(go.o): unexpectedly long symbol name of 6397 bytes in golang.org/x/text/unicode/cldr: |
"Fix" the linker, or fix the compiler? @crawshaw, you want this one? /cc @josharian |
CL https://golang.org/cl/21457 mentions this issue. |
Yes, all this code is auto-generated. Lots of nested structs. I could hoist some of the nested structs, which should reduce it a bit, but that would be very far from ideal. It should be allowed in my opinion. |
@mpvl, nobody has suggested you need to change your code. |
same problem here |
I had a followup to cl/21457 that introduces a new type printer for the type.* symbol names. It takes the type with placeholders for the package names and runs it through SHA-1, then prints the first few bytes of the hash (like we do with git commits). It then appends all the package names that appear in the type in appearance order. The result is consistently small types and slightly less IO during compilation. (My secondary motivation was a stopgap measure for shrinking the symbol table for -buildmode=shared, but I now have a much simpler hack for that I'm going to send later today.) Unfortunately it also makes the toolchain just a little harder to debug. Given it's already pretty hard to understand and debug, I don't think it's worth it. So I'd rather just land cl/21457 and make the linker's object reader handle long symbol names. I'll send another CL for that in a bit. |
CL https://golang.org/cl/21581 mentions this issue. |
Instead of writing out the type almost twice in the symbol name, teach the linker how to sort typelink symbols by their contents. This ~halves the size of typelink symbol names, which helps very large (6KB) names like those mentioned in #15104. This does not increase the total sorting work done by the linker, and makes it possible to use shorter symbol names for types. See the follow-on CL 21583. Change-Id: Ie5807565ed07d31bc477d20f60e4c0b47144f337 Reviewed-on: https://go-review.googlesource.com/21457 Reviewed-by: Ian Lance Taylor <iant@golang.org>
I caused a regression in 73edd7b (cmd/link: simplify readSymName, taking advantage of bufio.Reader) It made an assumption that symbol names were less than 4kb.
Failure seen here:
https://storage.googleapis.com/go-build-log/1f5b1b2b/linux-amd64_8877cb41.log
/cc @crawshaw @nigeltao
The text was updated successfully, but these errors were encountered: