Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
cmd/link: unexpectedly long symbol name #15104
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:
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:
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.
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 <email@example.com>