You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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/
The text was updated successfully, but these errors were encountered: