-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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
proposal: cmd/compile: expose -ptabs/-exporttypes flag to force compiler to emit ptabs/type info #58567
Comments
CC @golang/runtime |
Is this a format that we want to commit to supporting forever? |
Good question, not sure if it's aimed at me though...? Do all |
The compiler flags don't fall under the compatibility guarantee, but still once we start supporting something it's hard to stop. |
Could you explain more of your use case? I think what (and whether) to emit and the format would depend on how the data will be consumed. Thanks. |
Thanks--can you copy that text to this issue? |
Sure, I’ve been working on a JIT compiler (https://github.com/eh-steve/goloader/tree/master/jit#usage-and-configuration) which can build, load and unload arbitrary Go code and its dependencies from a running host binary, using the standard go toolchain (but bypassing the final link step - it uses archives directly from the compiler). It differs from std My (unsatisfying, but working) approach so far has been to first parse the JIT package and use the *syntax.FuncDecl and *syntax.VarDecl nodes to find all exports, and generate a function for each export to retrieve its *_type via reflection, and writing this temporary generated file into the package before actually compiling. This requires the package source path to be writable, and to ensure this is possible, I introduced a bunch of unnecessary module copying. Since this is an optional gcflag, it doesn't change the current compiler behaviour except when set, and doesn't prevent linker deadcode elimination, except for selected packages where the flag is set. I think the previous proposal wanted to always export ptabs for all exports in the main binary's moduledata to provide a string-to-function lookup (preventing deadcode elimination) which I agree would be unnecessary. |
As an alternative, I'd also be happy with a flag to tell the compiler to emit type data for global functions by skipping the |
dumpGlobal just affects DWARF. Is that all you need? |
For my particular use case, I think so? As far as I can tell, dumpGlobal still forces the inclusion of the runtime types into the archive because TypeLinksym() is called, and this ties the type symbol and global symbol together (via GoAuxType) in a way I can reconstruct an interface{} from, though I haven't tested this end to end yet.
If you think that's a less contentious approach, I'm happy to adjust the proposal? |
Following up on this, I don't actually need to for _, export := range typecheck.Target.Exports {
s := export.Linksym()
if strings.HasSuffix(s.Name, "..inittask") && s.OnList() {
continue
}
t := export.Type()
if t == nil || (t.IsPtr() && t.Elem() == nil) || t.IsUntyped() {
continue
}
s.Gotype = reflectdata.TypeLinksym(export.Type())
} This seems to run ok without any ICEs, but might need some tests updating? I'd imagine the linker deadcode pass will strip these surplus symbols from the final binary if they're not needed, so this might be fairly harmless, as it only affects compiler output (though I haven't checked) |
Currently compiler only emits ptabs for package
main
with-dynlink
, for-buildmode=plugin
. Access to type information for package exports may be useful in other contexts, and is a fairly unobtrusive change.The text was updated successfully, but these errors were encountered: