Originally my project had just x86 system call code in it (using 32 bit registers and int $0x80), but then I created a version called src3 that used 64 bit registers and syscall. That worked, until I created src4 which changed the argument to my _exit function so that it only handles a single byte as the desired process exit status value (in my tests anything that needed more than a byte to represent seemed to overflow in shell printouts, so I'm assuming that process exit status values are only 1 byte in size anyway). This broke my _exit function until I changed using syscall to int $0x80.
Asked
Active
Viewed 169 times
0
-
Uh, what? I've never been linking against a libc, these are my own definitions. – Draeton Apr 25 '14 at 21:37
-
Ok, show code of your _exit function. – osgx Apr 25 '14 at 22:14
-
The exit syscall takes an int, regardless of how it's getting truncated when returned to e.g. a shell. Though, it would be helpful if you tell us how it broke and what happened, and some code. – nos Apr 25 '14 at 22:43
-
See: [Exit codes bigger than 255 -- possible?](http://stackoverflow.com/questions/179565/exitcodes-bigger-than-255-possible/179652#179652). (No, this question is not a duplicate of that one, but it provides some information that is relevant to this.) – Jonathan Leffler Apr 25 '14 at 22:46
-
Does anyone here even know what syscall is? It's an x86 instruction, meant to replace int $0x80 (I guess, still wondering why syscall is used) for switching to kernel mode and invoking system call invoking code. – Draeton Apr 26 '14 at 01:05
-
According to a textbook I'm looking at now (The Linux Programming Interface), an equivalent called sysenter (does not mention syscall, making an assumption) is faster than int $0x80 for some reason. – Draeton Apr 26 '14 at 01:09
-
I still don't get why syscall is used because of how funky it seems to be. – Draeton Apr 26 '14 at 01:10