-
-
Notifications
You must be signed in to change notification settings - Fork 604
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
Support syscall instruction #590
Comments
FPC (Free Pascal) is another project which needs support of the syscall instruction. If we do not change the link line, and look at what failed, we see this stack trace:
This SYSTEM_FPSYSCALL$INT64$INT64$INT64$$INT64 is the free-pascal's system library's FpSysCall() function, defined in fpc's source code in fpcsrc/rtl/linux/x86_64/syscall.inc. Sadly, it is assembly-language code, which calls the syscall instruction directly, which we can see in that source code, or by disassembling the place where we got the #UD:
|
Yes, I think we should support the |
Hey, I would be up for this task since I want to run application that utilize OpenMP on OSv. |
You can see Pekka's (penberg) original proposed patch to support the "syscall" instruction in This patch should work at least sometime (Pekka tested it somehow) but you might want to look into other people's concerns about that patch in: Some of those issues (like the FS switching) might only be relevant to static executables (which think they own the world) and not to normal shared objects who just happen to call the syscall instruction here and there like in the above examples, so if we try to solve only this issue and not #522 or #212, we might not have to solve all the problems just yet. |
This is a trivial hello-world Free Pascal application. It does't currently work because of missing syscall instruction support. cloudius-systems/osv#590 Hopefully it will begin working when OSv adds syscall instruction support. Stack trace we get in fpc initialization function: 4 0x0000000000482754 in invalid_opcode (ef=0xffff800002a2b088) at arch/x64/exceptions.cc:320 5 <signal handler called> 6 0x0000100000c07b72 in SYSTEM_$$_FPSYSCALL$INT64$INT64$INT64$$INT64 () 7 0x0000100000c0839a in SYSTEM_$$_FPGETRLIMIT$LONGINT$PRLIMIT$$LONGINT () 8 0x0000000c000ff3b0 in ?? () 9 0x0000100000c2a357 in SYSTEM_$$_CHECKINITIALSTKLEN$QWORD$$QWORD () 10 0x0000000000000000 in ?? () Note that to see these function names, you'll need to remove the strip command from the script ppash.sh automatically generated by fpc, and run it again. This example was based on http://wiki.lazarus.freepascal.org/Free_Pascal_on_OSv but I wanted to not need the special linking instructions. Signed-off-by: Nadav Har'El <nyh@scylladb.com> Message-Id: <1472143611-31621-1-git-send-email-nyh@scylladb.com>
Enable "fast system calls" via the 'syscall' instruction on OSv. The instruction is used by Go programs on Linux/x86-64 for system calls. Fixes cloudius-systems#590 Signed-off-by: Pekka Enberg <penberg@scylladb.com> Signed-off-by: Benoît Canet <benoit@sylladb.com> Message-Id: <1472389268-11004-1-git-send-email-benoit@scylladb.com>
The libgomp library (gcc's implementation of OpenMP) does the strange thing of calling the "syscall" machine instruction, instead of the syscall() library function - perhaps in a misplaced attempt to save a few cycles.
In gcc4.9.2/libgomp/config/linux/x86/futex.h, there is:
And more of that ilk.
If we want to support an unmodified libgomp.so, we therefore need to support the syscall instruction, and not just the syscall() library function.
In November Pekka posted a patch to the mailing list, titled "[RFC PATCH 08/14] x64: 'syscall' instruction support", for supporting the syscall instruction. This was useful for issue #522 and issue #212, but we now see there are more situations why it can be useful, so I think we should just go ahead and support it.
The text was updated successfully, but these errors were encountered: