[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #8 from Andrew Pinski --- This file is compiling for gnu/Linux or musl/linux or uclibc/Linux which means it is both the libc abi and Linux (kernel) abi. So I don't see this as a bug still. If you have a target that is Linux kernel abi, your libgomp should not use this file to use futex directly.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #7 from Andreas Schwab --- syscall(2) is a standard Unix libc interface.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #6 from Nadav Har'El --- Andrew, the syscall instruction may indeed be the only ABI of the Linux kernel. But I didn't create this issue on the Linux kernel mailing list, rather on the libgomp library's issue tracker. Looking a the libgomp it already uses the "glibc" API (and therefore ABI), and not just the system call instruction. It uses malloc() and friends (and not the sbrk() system call), stdio, pthread_*(), and varios str* functions; So I was wondering why not use syscall() glibc function instead of duplicating its definition. I could understand a response which would say something like "We want libgomp to be usable without glibc, so we try to avoid using glibc functions and use x86 instructions directly". But unless I'm missing something, libgomp isn't actually usable without glibc.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #5 from Andrew Pinski --- (In reply to Nadav Har'El from comment #4) > *That* is the Linux ABI, not the x86-64 instruction. Actually the Linux ABI is just the syscall ABI, nothing more and nothing less. The GNU/Linux ABI (glibc) is built on top of the syscall ABI.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #4 from Nadav Har'El --- There is a fine line between relying on "Linux" (e.g., the glibc ABI functions as defined in LSB for example), and relying on obscure architecture-specific tricks (like calling the syscall *instruction* in a way that only works on x86-64). The latter may be justified when performance is the ultimate concern, but I wonder if this is the case here (as I explained in my previous comments). When is not the case, I don't understand why not use the syscall() library function. *That* is the Linux ABI, not the x86-64 instruction. This is not only an OSv question (although my attempt to use it in OSv brought up this question). It's also a question why all this complexity is needed, when glibc's syscall() function already has it. It looks to me like gratuitous duplication, unless I'm missing the real reason why this was done.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- Not a bug, if you want to use OSv, then the OS is not linux anymore.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #2 from Nadav Har'El --- Hi, What was the intention behind this "intentionally"? As I mentioned above, I believe the tiny performance saving of not calling the syscall() function are minimal, because if I understand correctly it's only called in rare cases when there is contention, and when the context-switch overhead would be large anyway. And even if it's not rare, isn't the syscall overhead significantly larger than the syscall() function's additional overhead (copying a couple of registers, etc.)? Just using and syscall() would have made all this code simpler, and avoid repeating code already in glibc. Unless I'm missing something important here... Regarding OSv (see http://osv.io/), the idea there is that it is able to run unmodified Linux dynamically-linked binaries. Our C library is different (not glibc), but other libraries and executables which call libc functions can run unmodified, and libgomp should not be an exception. The plan is to take an unmodified libgomp.so from some Linux distribution and just run it, without recompiling. It's not impossible for us also to support the "syscall" instruction, but I was just wondering why we want to: libgomp is the first library we've seen to call the syscall instruction directly instead of just calling the syscall() libc function, and I was wondering if there is good justification for that.
[Bug libgomp/65070] libgomp calls syscall instruction directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65070 --- Comment #1 from Jakub Jelinek --- It is intentionally written that way. Why would you want to use linux specific code on an OS that isn't linux?
