-
Notifications
You must be signed in to change notification settings - Fork 18.8k
Open
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Milestone
Description
The code used to make system calls from the runtime is a mess and a big pain point when making OS-level changes in the runtime.
Quick summary of some of the pain points:
- Completely independent implementation from package
syscall. - System call stubs exist in a variety of OS- and arch-specific
sys*files (57, to be precise, mostly assembly), totaling ~23k lines of code [1], which is 100% hand-written. Adding a new syscall stub often requires adding new assembly to 10+ files. - There is no generic
Syscallfunction that can be used to make an arbitrary system call. You must add a new stub to make a new call.
Some things we could do to improve the situation:
- Add generic
Syscallfunctions, used by other stubs. And/or use code generation to generate stubs rather than doing so manually. - Move syscall code to a new package (like
runtime/internal/syscallor perhapsruntime/internal/linux?) to avoid littering theruntimepackage itself with so many files. - Make package
syscalldepend on the runtime'sSyscallstub so we only have a single implementation.
[1] Some of this code is things other than syscall stubs, like thread entrypoints.
aclements, cherrymui, cristaloleg, beoran, mdlayher and 7 morecristaloleg
Metadata
Metadata
Assignees
Labels
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Type
Projects
Status
In Progress