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.

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

debug/dwarf: No method to lookup type by type signature #10318

Open
aclements opened this issue Apr 2, 2015 · 2 comments
Open

debug/dwarf: No method to lookup type by type signature #10318

aclements opened this issue Apr 2, 2015 · 2 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Milestone

Comments

@aclements
Copy link
Member

The dwarf package internally has support for finding type entries by type signature, but it does not expose this to users of the dwarf package. (*Data).Type takes an "info" offset of a type entry and understands internally how to follow AttrType fields within that type that reference other types by signature. But AttrType can also be used on program entities to reference the type of that entity (e.g., the type of a variable), and any occurrence of AttrType can be either an "info" offset, which can be resolved by the package user; or a type signature, which cannot currently be resolved by the package user.

In practice this often isn't an issue because compilers that emit type signatures typically do so for typedef'd types (since there's little value in doing this for a single instance type), so the AttrType of the program entity will be an "info" offset of the typedef and that, in turn, will reference the type signature. However, compilers are free to do what they want and may emit type signatures in program entities, making the current API fragile. There's also no way for a caller to do its own decoding of the type structure if it references types by signature.

Consider adding an API to fetch a type by its signature. This could be accomplished by simply exposing (_Data).sigToType, but this puts the burden of distinguishing "info" offests and type signatures on the user. We could instead add a variant of (_Data).Type that takes a Val (really an interface{}) and does the appropriate kind of lookup.

Orthogonally, this new method could return either a dwarf.Type or a dwarf.Entry. Returning dwarf.Type forces the user to accept the dwarf package's decoding of the type structure. On the other hand, a method to resolve a type offset or signature into an Entry and another method to decode an Entry into a Type would be more flexible and would expose the ability to read the types section without forcing the caller to use dwarf.Type.

See related discussion at https://go-review.googlesource.com/#/c/7280/

@rsc
Copy link
Contributor

rsc commented Apr 10, 2015

If you need this for a real program, sure.

@rsc rsc added this to the Go1.5Maybe milestone Apr 10, 2015
@rsc
Copy link
Contributor

rsc commented Jun 29, 2015

Too late for Go 1.5.

@rsc rsc modified the milestones: Unplanned, Go1.5Maybe Jun 29, 2015
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jul 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

3 participants