Re: errno assignment in _syscall macros and glibc

Re: errno assignment in _syscall macros and glibc

[Ralf Baechle]

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

Re: errno assignment in _syscall macros and glibc

[Andreas Jaeger]

>>>>> 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

Re: errno assignment in _syscall macros and glibc

[Ralf Baechle]

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

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> 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.

Don't make it too private. glibc is still worryingly large for some embedded
applications. Between a libc and the kernel yes, between glibc and the kernel
no.

Alan

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> 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.

Don't make it too private. glibc is still worryingly large for some embedded
applications. Between a libc and the kernel yes, between glibc and the kernel
no.

Alan

Re: errno assignment in _syscall macros and glibc

[Ralf Baechle]

On Sun, Jun 25, 2000 at 08:26:42PM +0100, Alan Cox wrote:

> > 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.
> 
> Don't make it too private. glibc is still worryingly large for some embedded
> applications. Between a libc and the kernel yes, between glibc and the kernel
> no.

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.

  Ralf

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> 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!!)

Alan

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> 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!!)

Alan

Re: errno assignment in _syscall macros and glibc

[Ralf Baechle]

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

Re: errno assignment in _syscall macros and glibc

[Jay Carlson]

> > 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!!)

Does newlib work under Linux?  I thought it was missing (for example) the
syscalls, and generally needed work to be ported to Linux.  I'm interested
in helping with this, if people are already doing it.

*BSD libc has been suggested by a few people.

BTW, MIPS32 is not a synonym for 32-bit MIPS architecture.  :-( This appears
to be the fault of marketing people.  Quoting
http://www.mips.com/products/s2p5.html :

---
The MIPS32T architecture is a superset of the previous MIPS IT and MIPS IIT
Instruction Set Architectures (ISA) and incorporates powerful new
instructions specifically for embedded applications, as well as proven
memory management and privileged mode control mechanisms previously found
only in 64-bit R4000® and R5000® MIPS® processors.
---

It's got conditional move, multiply/add, count leading ones/zeroes, and some
other stuff.  I don't know of any shipping PDAs using MIPS32 chips.

Jay

Re: errno assignment in _syscall macros and glibc

[Jay Carlson]

> > 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!!)

Does newlib work under Linux?  I thought it was missing (for example) the
syscalls, and generally needed work to be ported to Linux.  I'm interested
in helping with this, if people are already doing it.

*BSD libc has been suggested by a few people.

BTW, MIPS32 is not a synonym for 32-bit MIPS architecture.  :-( This appears
to be the fault of marketing people.  Quoting
http://www.mips.com/products/s2p5.html :

---
The MIPS32T architecture is a superset of the previous MIPS IT and MIPS IIT
Instruction Set Architectures (ISA) and incorporates powerful new
instructions specifically for embedded applications, as well as proven
memory management and privileged mode control mechanisms previously found
only in 64-bit R4000® and R5000® MIPS® processors.
---

It's got conditional move, multiply/add, count leading ones/zeroes, and some
other stuff.  I don't know of any shipping PDAs using MIPS32 chips.

Jay

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> Does newlib work under Linux?  I thought it was missing (for example) t=
> he
> syscalls, and generally needed work to be ported to Linux.  I'm interes=

You would need to add the syscalls yes. Also the Cygnus^WRed Hat folks tell
me that the eCos libc is built from and replaces newlib.

> *BSD libc has been suggested by a few people.

Good idea - how does it compare ?

> Jay
> 
> 

Re: errno assignment in _syscall macros and glibc

[Alan Cox]

> Does newlib work under Linux?  I thought it was missing (for example) t=
> he
> syscalls, and generally needed work to be ported to Linux.  I'm interes=

You would need to add the syscalls yes. Also the Cygnus^WRed Hat folks tell
me that the eCos libc is built from and replaces newlib.

> *BSD libc has been suggested by a few people.

Good idea - how does it compare ?

> Jay
> 
>