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/compile: move DWARF go.info.* symbol generation out of the linker #22094

Open
crawshaw opened this Issue Sep 30, 2017 · 6 comments

Comments

Projects
None yet
6 participants
@crawshaw
Contributor

crawshaw commented Sep 30, 2017

The linker generates go.info.* symbols for Go types. It does so by parsing the contents of type.* symbols. It also depends on the names of these type.* symbols to successfully find other others.

All of this makes the linker quite fragile. The logic in decodesym.go has to be kept in sync with the compiler's rtype code generation, the runtime, and the reflect package. Depending on the type. symbol names interacts poorly with other things the linker wants to do, like rename symbols.

An easier place to generate these go.info.* symbols is in the compiler, right next to the code that generates the type.* symbols. The data structures are all nicely laid out in memory and don't require the hairy partial-decoding we do in the linker.

It looks like a tiny part of this has already been done, the compiler generates go.info symbols for vars. It should be possible to move the rest of the type symbols to the compiler piecemeal.

cc @heschik @dr2chase

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 4, 2017

Is there any DWARF generation that has to happen in the linker? Or should we try to move all DWARF generation into the compiler/assembler?

For example, we also generate the .debug_line section from decoding the PC-Value tables. If we generated them in the compiler, we could include column position information.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 4, 2017

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Oct 4, 2017

Most linkers do not generate any DWARF information at all.

@heschik

This comment has been minimized.

Contributor

heschik commented Oct 9, 2017

I think this would be nice, and might incidentally help with #21945 by giving us a CU per package, but I don't see an overwhelming benefit here. Maybe I'm missing something.

decodesym.go seems to be a bit of a grab bag; some of its functions are only used by the DWARF generation, but others are only used in dead code elimination, and others are used in other parts of the linker. Seems unlikely we'll ever delete the code wholesale, though.

Can you give an example of a case where this has given us trouble? Most of it hasn't changed in a solid year other than your recent refactorings.

I wonder how many redundant type DIEs we'd end up creating, and how much of a performance impact that would have on the linker. Packages should carry DIEs for types they declare, and we can interpret strings and such as being in the runtime package, so those can be referenced rather than recreated. What about maps and other derived types? I guess we can do whatever we do for their alg functions.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Oct 9, 2017

I wonder how many redundant type DIEs we'd end up creating, and how much of a performance impact that would have on the linker.

I would expect the number of redundant DIEs to be equal to the number of redundant reflect type descriptors.

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Mar 29, 2018

@dr2chase dr2chase modified the milestones: Go1.11, Go1.12 Jun 26, 2018

@griesemer

This comment has been minimized.

Contributor

griesemer commented Dec 5, 2018

Too late for 1.12.

@griesemer griesemer modified the milestones: Go1.12, Go1.13 Dec 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment