This is the mail archive of the libc-alpha@sourceware.cygnus.com mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Various] errno assignment in _syscall macros and glibc


On the MIPS list is currently a discussion about the inclusion of
<asm/unistd.h> in <sys/syscalls.h> (I'm appending some emails from the
discussion below).  <asm/unistd.h> contains all those __NR_* defines
for the syscalls (which we also get via <bits/syscall.h> as SYS_) and
also syscall defines which use errno directly (here's the ia32 version):
#define __syscall_return(type, res) \
do { \
        if ((unsigned long)(res) >= (unsigned long)(-125)) { \
                errno = -(res); \
                res = -1; \
        } \
        return (type) (res); \
} while (0)

Since these are obviously wrong for glibc, we shouldn't import them at
all.

What shall we do?  I would remove just the inclusion of <asm/unistd.h>
from <sys/syscalls.h>.

Ralf seems to even suggest to remove <sys/syscalls.h> completly.

The manual page for llseek mentions:
       _syscall5(int,  _llseek,  uint,  fd, ulong, hi, ulong, lo,
       loff_t *, res, uint, wh);

_syscall5 uses __syscall_return.  Either we should forbid _syscall5
etc. or we should add in <sys/syscalls.h> a multithread-safe version
instead of the broken one from the kernel.

What do you think?

Andreas


Subject: Topics

Topics:
   Re: errno assignment in _syscall macros and glibc
   Re: errno assignment in _syscall macros and glibc
   Re: errno assignment in _syscall macros and glibc
   Re: errno assignment in _syscall macros and glibc



On Sun, Jun 25, 2000 at 11:26:33AM +0200, Andreas Jaeger wrote:

> The question remains what we should do with glibc 2.2.  Currently
> <sys/syscalls.h> includes <asm/unistd.h> and this makes _syscall0 and
> friends available to userspace. 
> 
> I couldn't find any reference to <sys/syscalls.h> in the ABI and
> consider dropping the include of <asm/unistd.h> since it's not needed
> at all.
> 
> Any objections or better suggestions?

I will take his report as a real bug but for another reason.  The kernel
has a global variable errno which at least on i386 get the returned
error value.  Fixing this one will magically fix userland.

Still everybody should be aware that using your own syscall wrappers
can be _very_ dangerous.  I saw an attempt to use pread / pwrite which
was ok on Intel but might have corrupted data on MIPS due to different
calling conventions.  You have been warned.

Andreas - I think the syscall interface should finally officially be
declared a private interface between libc and the kernel, that is nobody
except these two should use it.  Many of the other attempts to use it
have been quite problematic - portabilitywise and worse.

  Ralf





>>>>> Ralf Baechle writes:

Ralf> On Sun, Jun 25, 2000 at 11:26:33AM +0200, Andreas Jaeger wrote:
>> The question remains what we should do with glibc 2.2.  Currently
>> <sys/syscalls.h> includes <asm/unistd.h> and this makes _syscall0 and
>> friends available to userspace. 
>> 
>> I couldn't find any reference to <sys/syscalls.h> in the ABI and
>> consider dropping the include of <asm/unistd.h> since it's not needed
>> at all.
>> 
>> Any objections or better suggestions?

Ralf> I will take his report as a real bug but for another reason.  The kernel
Ralf> has a global variable errno which at least on i386 get the returned
Ralf> error value.  Fixing this one will magically fix userland.

Ralf> Still everybody should be aware that using your own syscall wrappers
Ralf> can be _very_ dangerous.  I saw an attempt to use pread / pwrite which
Ralf> was ok on Intel but might have corrupted data on MIPS due to different
Ralf> calling conventions.  You have been warned.

Ralf> Andreas - I think the syscall interface should finally officially be
Ralf> declared a private interface between libc and the kernel, that is nobody
Ralf> except these two should use it.  Many of the other attempts to use it
Ralf> have been quite problematic - portabilitywise and worse.

I'm considering to commit the appended patch.  I've compiled glibc
with it and didn't notice any problems.  If nobody objects, I'll apply
it tomorrow.

Ralf, are there any other places that needs to be changed?  What do
you think of adding 
#ifdef KERNEL
around _syscallX in <asm/unistd.h> ?

Andreas

2000-06-25  Andreas Jaeger  <aj@suse.de>

	* sysdeps/unix/sysv/linux/mips/sys/syscall.h: Don't include
	<asm/unistd.h> - we don't need any of these at all in glibc or
	user programs.

============================================================
Index: sysdeps/unix/sysv/linux/mips/sys/syscall.h
--- sysdeps/unix/sysv/linux/mips/sys/syscall.h	2000/06/23 07:55:36	1.4
+++ sysdeps/unix/sysv/linux/mips/sys/syscall.h	2000/06/25 18:51:00
@@ -19,11 +19,6 @@
 #ifndef	_SYSCALL_H
 #define	_SYSCALL_H	1
 
-/* This file should list the numbers of the system the system knows.
-   But instead of duplicating this we use the information available
-   from the kernel sources.  */
-#include <asm/unistd.h>
-
 /*
  * SVR4 syscalls are in the range from 1 to 999
  */


-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de





On Sun, Jun 25, 2000 at 08:53:30PM +0200, Andreas Jaeger wrote:

> I'm considering to commit the appended patch.  I've compiled glibc
> with it and didn't notice any problems.  If nobody objects, I'll apply
> it tomorrow.
> 
> Ralf, are there any other places that needs to be changed?

libc/sysdeps/unix/sysv/linux/sys/syscall.h should be patched the same way.

I remember that I once saw a program the __NR_ syscall numbers imported
via unistd.h.  Fixing won't be a big deal.

> What do you think of adding 
> #ifdef KERNEL
> around _syscallX in <asm/unistd.h> ?

__KERNEL__ that is ...

Slightly radical but I like it.  It'll break some programs which are using
the _syscallX() macros to get syscalls which libc doesn't yet have wrappers
for just to get away without fixing / upgrading libc.  Those people still
can use syscall(3) in such a case.

  Ralf





On Sun, Jun 25, 2000 at 10:25:48PM +0100, Alan Cox wrote:

> > Sure; these days glibc is more or less synonym with libc and I was using
> > it in that sense.
> > 
> > What small, portable libcs do we have available anyway?  Some mipers will
> > want one.
> 
> I've been playing with the Linux8086 libc which is tiny but not portable when
> Prumpf pointed out that Cygnus newlib is designed for precisely this job. Its
> about 250K MIPS32 (my PDA has mips32/mips64 but not mips16 - duh!!)

Oh promised lands of small happy libcs :-)

Back to the original problem - the i386 <asm/unistd.h> __syscall_return
macro which is used by the _syscallX macros set the errno variable - even
inside the kernel.  In the age of SMP this looks broken - at least nothing
seems to rely on it.  So how about removing the whole errno thing from
there?

  Ralf





-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]