Skip to content
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

syscall: int 0x80 is still used by syscalls in Linux #32140

Closed
faissaloo opened this issue May 19, 2019 · 4 comments
Closed

syscall: int 0x80 is still used by syscalls in Linux #32140

faissaloo opened this issue May 19, 2019 · 4 comments

Comments

@faissaloo
Copy link

@faissaloo faissaloo commented May 19, 2019

int 0x80 is deprecated and extremely slow, new x86 software should be using sysenter, you can find the calling convention on this SO answer

@ALTree ALTree changed the title int 0x80 is still used by syscalls in Linux syscall: int 0x80 is still used by syscalls in Linux May 19, 2019
@ALTree ALTree added this to the Unplanned milestone May 19, 2019
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 20, 2019

Which platform are you talking about? As far as I know on amd64 we always use the SYSCALL instruction.

@martisch
Copy link
Contributor

@martisch martisch commented May 20, 2019

Current Minimum Go CPU requirement for 386 is Pentium MMX which does not support sysenter.
Therefore changing this for all supported Go archs would need a test for the specific CPUID bit and a bump in minimum CPU requirements. https://golang.org/doc/install/source#environment

See

// Most linux systems use glibc's dynamic linker, which puts the
for why int 0x80 is used:

// Most linux systems use glibc's dynamic linker, which puts the
// __kernel_vsyscall vdso helper at 0x10(GS) for easy access from position
// independent code and setldt in runtime does the same in the statically
// linked case. However, systems that use alternative libc such as Android's
// bionic and musl, do not save the helper anywhere, and so the only way to
// invoke a syscall from position independent code is boring old int $0x80
// (which is also what syscall wrappers in bionic/musl use).
//
// The benchmarks also showed that using int $0x80 is as fast as calling
// *%gs:0x10 except on AMD Opteron. See https://golang.org/cl/19833
// for the benchmark program and raw data.

Are there new benchmarks showing Go to better off not using int 0x80 with an alternative supported with bionic, musl and position independent code? This would be interesting especially on CPUs that dont support amd64 as the newer ones are likely to be mostly used with the amd64 arch which supports sysenter.

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 22, 2019

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

@gopherbot gopherbot closed this Jun 22, 2019
@golang golang locked and limited conversation to collaborators Jun 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.