Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.arch    |    Apparently more than just beeps & boops    |    131,241 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 129,392 of 131,241    |
|    Anton Ertl to Anton Ertl    |
|    Re: System calls (was: VAX)    |
|    14 Aug 25 07:58:41    |
      From: anton@mips.complang.tuwien.ac.at              anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:       >I am pretty sure that in the old times, Linux-i386 indicated failure       >by returning a value with the MSB set, and the wrapper just checked       >whether the return value was negative.              I have now checked this by chrooting into an old Red Hat 6.2 system       (not RHEL) with glibc-2.1.3 (released in Feb 2000) and its system call       wrappers. And already those wrappers use the current way of       determining whether a system call returns an error or not:              For mmap():              0xf7fd984b <__mmap+11>: int $0x80       0xf7fd984d <__mmap+13>: mov %edx,%ebx       0xf7fd984f <__mmap+15>: cmp $0xfffff000,%eax       0xf7fd9854 <__mmap+20>: ja 0xf7fd9857 <__mmap+23>              Bottom line: If Linux-i386 ever had a different way of determining       whether a system call has an error result, it was changed to the       current way early on. Given that IIRC I looked into that later than       in 2000, my memory is obviously not of Linux. I must have looked at       source code for a different system.              Actually, the whole wrapper is short enough to easily understand what       is going on:              0xf7fd9840 <__mmap>: mov %ebx,%edx       0xf7fd9842 <__mmap+2>: mov $0x5a,%eax       0xf7fd9847 <__mmap+7>: lea 0x4(%esp,1),%ebx       0xf7fd984b <__mmap+11>: int $0x80       0xf7fd984d <__mmap+13>: mov %edx,%ebx       0xf7fd984f <__mmap+15>: cmp $0xfffff000,%eax       0xf7fd9854 <__mmap+20>: ja 0xf7fd9857 <__mmap+23>       0xf7fd9856 <__mmap+22>: ret       0xf7fd9857 <__mmap+23>: push %ebx       0xf7fd9858 <__mmap+24>: call 0xf7fd985d <__mmap+29>       0xf7fd985d <__mmap+29>: pop %ebx       0xf7fd985e <__mmap+30>: xor %edx,%edx       0xf7fd9860 <__mmap+32>: add $0x400b,%ebx       0xf7fd9866 <__mmap+38>: sub %eax,%edx       0xf7fd9868 <__mmap+40>: push %edx       0xf7fd9869 <__mmap+41>: call 0xf7fd7f80 <__errno_location>       0xf7fd986e <__mmap+46>: pop %ecx       0xf7fd986f <__mmap+47>: pop %ebx       0xf7fd9870 <__mmap+48>: mov %ecx,(%eax)       0xf7fd9872 <__mmap+50>: or $0xffffffff,%eax       0xf7fd9875 <__mmap+53>: jmp 0xf7fd9856 <__mmap+22>              One interesting difference from the current way of invoking a system       call is that (as far as I understand the wrapper) the wrapper loads       the arguments from memory (IA-32 ABI passes parameters on the stack)       into registers and then performs the system call in some newfangled       way, whereas here the arguments are left in memory, and apparently a       pointer to the first argument is passed in %ebx; the system call is       invoked in the old way: int $0x80.              - anton       --       'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'        Mitch Alsup, |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca