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
We have code scattered around that knows about the insides of cmd/compile's object files, in the compiler, the go/types importer, the linker, and some packages in x/tools. It'd be nice to consolidate this knowledge a bit, because the object files are non-trivial and they change over time, and the versioning support is non-trivial.
It's unfortunate to add API surface area in the main repo, but it seems like the natural place for it. Most of the shared implementation for the toolchain and go/types could be in an internal package, with minimal API exposed at debug/goobj as strictly needed for external tools. See CL 41053 for one such use.
This proposal obviously needs fleshing out, but I want to get an initial pulse before putting in much effort on the design.
Let's leave things as they are for now until we've cleaned up the object format (which is not a high priority right now - nothing is slowing us down significantly).
We have code scattered around that knows about the insides of cmd/compile's object files, in the compiler, the go/types importer, the linker, and some packages in x/tools. It'd be nice to consolidate this knowledge a bit, because the object files are non-trivial and they change over time, and the versioning support is non-trivial.
It's unfortunate to add API surface area in the main repo, but it seems like the natural place for it. Most of the shared implementation for the toolchain and go/types could be in an internal package, with minimal API exposed at debug/goobj as strictly needed for external tools. See CL 41053 for one such use.
This proposal obviously needs fleshing out, but I want to get an initial pulse before putting in much effort on the design.
cc @griesemer
The text was updated successfully, but these errors were encountered: