Skip to content

runtime: clean up system call code #51087

Open
@prattmic

Description

@prattmic

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 Syscall function 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 Syscall functions, 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/syscall or perhaps runtime/internal/linux?) to avoid littering the runtime package itself with so many files.
  • Make package syscall depend on the runtime's Syscall stub so we only have a single implementation.

[1] Some of this code is things other than syscall stubs, like thread entrypoints.

cc @aclements @mknyszek @cherrymui

Activity

added this to the Backlog milestone on Feb 8, 2022
aclements

aclements commented on Feb 8, 2022

@aclements
Member

And/or use code generation to generate stubs rather than doing so manually.

All or most of the information we would need to generate the stubs is already in the syscall package. The needs of the syscall package are of course a bit different, but the metadata should be effectively the same.

Orthogonal to code generation, given a generic runtime Syscall function (or a few of them for different numbers of arguments), would there even be any overhead to having the stubs be in Go rather than assembly? In addition to significantly reducing the amount of assembly, I think this would encourage us to do better error handling.

cherrymui

cherrymui commented on Feb 8, 2022

@cherrymui
Member

Just to add another pain point: the stubs handle errors differently. Some returns errno (negated or not?), some just crash hard (writing to an invalid address), which is difficult to debug sometimes.

gopherbot

gopherbot commented on Feb 8, 2022

@gopherbot
Contributor

Change https://go.dev/cl/383999 mentions this issue: runtime/internal/syscall: new package for linux

added
NeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.
on Feb 8, 2022
ii64

ii64 commented on Feb 23, 2022

@ii64

Seems this introduce build error, i got:
gofrontend commit 45fd14ab8baf5e86012a808426f8ef52c1d77943
image

cherrymui

cherrymui commented on Feb 23, 2022

@cherrymui
Member

@ii64 this issue is about a plan for the future, not what has happened. Your comment is unrelated to this issue.

Looks like you are using gollvm. What version of gollvm are you using? Try updating to the latest. If that still fail, please file a new issue. Thanks.

modified the milestones: Backlog, Go1.19 on Feb 24, 2022
gopherbot

gopherbot commented on Feb 28, 2022

@gopherbot
Contributor

Change https://go.dev/cl/388094 mentions this issue: test: rename live_syscall.go to live_uintptrkeepalive.go

gopherbot

gopherbot commented on Feb 28, 2022

@gopherbot
Contributor

Change https://go.dev/cl/388477 mentions this issue: syscall: define Syscall in terms of RawSyscall

35 remaining items

gopherbot

gopherbot commented on Aug 8, 2022

@gopherbot
Contributor

Change https://go.dev/cl/421994 mentions this issue: runtime: move epoll syscalls to runtime/internal/syscall

gopherbot

gopherbot commented on Sep 30, 2022

@gopherbot
Contributor

Change https://go.dev/cl/437295 mentions this issue: Revert "runtime: move epoll syscalls to runtime/internal/syscall"

gopherbot

gopherbot commented on Oct 7, 2022

@gopherbot
Contributor

Change https://go.dev/cl/440115 mentions this issue: runtime: move epoll syscalls to runtime/internal/syscall

modified the milestones: Go1.20, Backlog on Jan 11, 2023
gopherbot

gopherbot commented on Sep 12, 2024

@gopherbot
Contributor

Change https://go.dev/cl/612715 mentions this issue: runtime: use getrandom(2) for readRandom on Linux

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

NeedsInvestigationSomeone 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.

Type

No type

Projects

Status

In Progress

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @prattmic@aclements@gopherbot@cherrymui@ii64

      Issue actions

        runtime: clean up system call code · Issue #51087 · golang/go