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: include DWARF declaration position for types #25064

Open
dlsniper opened this Issue Apr 25, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@dlsniper
Contributor

dlsniper commented Apr 25, 2018

The linker should include the declaration position for types so that we can use this information in editors and disambiguate where the types come from.

The easiest to replicate the confusion is to have a project which has multiple main packages and to try to go to a specific type declared in both those main package. In this case, the type contains only the main.TypeName information so an editor would be forced to implement additional logic to infer where the main package is located in the binary.

Thank you.

@heschik heschik added the Debugging label Apr 25, 2018

@heschik

This comment has been minimized.

Contributor

heschik commented Apr 25, 2018

AFAIK, declaration coordinates for types are not stored anywhere in the object files that the linker gets. Type information in the linker comes from the runtime type structures, so we'd have expand those, which would increase memory usage and binary size even when DWARF was disabled. That's unlikely to happen unless there's a really compelling case for it.

If type DIEs were generated in the compiler, this would be more feasible, but that's a big project. We might get to it eventually.

@dlsniper

This comment has been minimized.

Contributor

dlsniper commented Apr 25, 2018

Thank you for your quick reply. I realize that this is not necessarily a priority in the big picture. Would producing the package import path, for example github.com/dlsniper/demo/cmd/pkg.Type be a viable workaround? This would allow to have consistency with all other package names/paths.

@heschik

This comment has been minimized.

Contributor

heschik commented Apr 25, 2018

This isn't my area of expertise, but I believe that main is special and doesn't actually have an import path at all, since it's never imported. If it did that would be a good solution.

Does DW_AT_compilation_dir help at all?

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