Proposal: selectively reuse GOROOT assembly in replacement packages

Background

LLGo can translate selected Plan 9 assembly for ordinary and additive packages, but replacement packages intentionally skip the original GOROOT .s files. As a result, the replacement syscall package implements rawSyscallNoError through libc syscall, and PR #2098 adds an amd64 gettimeofday libc bridge because the matching Go implementation lives in syscall/asm_linux_amd64.s.

These bridges are correct, but they add a libc dependency and duplicate behavior already maintained by Go. This is a focused follow-up to #1582, not a return to a second general syscall intrinsic system.

Proposal

Evaluate an explicit, target-aware allowlist for reusing selected GOROOT assembly from replacement packages.

• select by package, GOOS, GOARCH, and preferably TEXT symbol rather than enabling every .s file in the package
• pass selected code through the existing Plan 9 assembly translator and ABI validation
• diagnose duplicate or incompatible symbols instead of silently preferring one implementation
• keep replacement-package assembly as the default; GOROOT reuse must be opt-in
• first evaluate Linux syscall.rawSyscallNoError and amd64 syscall.gettimeofday

Symbol-level selection matters because one upstream file may also define helpers such as rawVforkSyscall, which LLGo already handles separately.

Linux vDSO initialization

The amd64 Go gettimeofday assembly first calls runtime.vdsoGettimeofdaySym when available and falls back to SYS_gettimeofday. A vDSO is a small kernel-provided ELF image mapped into each process; calling it avoids a kernel transition while preserving kernel timekeeping semantics.

Reusing this assembly therefore also requires LLGo to initialize the vDSO symbol table:

1. locate AT_SYSINFO_EHDR in the process auxiliary vector
2. parse the vDSO ELF dynamic and version tables
3. resolve supported symbols such as __vdso_gettimeofday and __vdso_clock_gettime
4. publish the resolved addresses expected by reused Go assembly
5. retain a raw-syscall fallback when the vDSO or a symbol is unavailable

C-library modes need special consideration because LLGo does not own process startup. Initialization must work when loaded by a foreign executable and must not assume the Go runtime startup path.

Necessity and scope

This facility is justified only if an inventory finds multiple self-contained helpers whose reuse materially improves correctness, portability, performance, or dependency reduction. If gettimeofday is the only useful case, the small libc bridge in #2098 is preferable to a new selection mechanism.

Android, seccomp environments, embedded targets, and architectures unsupported by the assembly translator must keep appropriate libc or LLGo-specific fallbacks.

Acceptance criteria

• document the candidate inventory and the keep-bridge versus reuse decision for each symbol
• no duplicate symbols in executable, c-shared, or c-archive modes
• test return values and errno behavior, not only symbol resolution
• test vDSO present and forced-fallback paths on Linux amd64
• preserve the existing target and Go-version compatibility matrix

Related: #1582, #1690, #2098

Start by reviewing syscall/asm_linux_amd64.s, the existing replacement syscall implementation, and the behavior described in #2098. Inventory candidate symbols and determine whether reuse or the existing libc bridge is preferable, then investigate vDSO initialization and fallback behavior. Done means documented decisions, no duplicate symbols, validated errno and return values, and coverage for vDSO and fallback paths.