home bbs files messages ]

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,    
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca