linux-mips-fnet
[Top] [All Lists]

Re: errno assignment in _syscall macros and glibc

To: "Mike Klar" <mfklar@ponymail.com>
Subject: Re: errno assignment in _syscall macros and glibc
From: Andreas Jaeger <aj@suse.de>
Date: 25 Jun 2000 11:26:33 +0200
Cc: <linux-mips@fnet.fr>
In-reply-to: "Mike Klar"'s message of "Sat, 24 Jun 2000 12:42:10 -0700"
Mail-copies-to: never
References: <NDBBIDGAOKMNJNDAHDDMCEODCKAA.mfklar@ponymail.com>
Sender: aj@suse.de
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Capitol Reef)
>>>>> Mike Klar writes:

 > Hi all,
 > I've run across a problem with user apps that use the _syscall[0-7] macros
 > in asm-mips/unistd.h.  With the latest Linux-MIPS glibc release (the
 > 2.0.6-5lm version), they're not getting errno set properly for error
 > conditions.  In particular, this breaks recent versions of modutils.

 > The problem is this:  In user space, errno is now a per-thread value.  This
 > seems like a good thing to me, but it means that the assignment of errno is
 > no longer a simple assignment, but now involves a function call to retrieve
 > a pointer to errno.  This trips up the _syscall macros in unistd.h because
 > they all do:
 > errno = __res;
 > where __res is declared to be the v0 register, which is set by the syscall
 > itself.  Meanwhile, the function that retrieves the pointer to errno returns
 > it in... v0.  So errno winds up getting set to the address of errno.  This
 > doesn't affect _syscall usage in kernel code, because errno is a simple
 > assignment in that case, nor does it affect glibc itself, since glibc
 > doesn't seem to use the _syscall macros.

 > I worked around this problem by adding to each _syscall macro:
 > unsigned long __res_save; \
 > and changing:
 > errno = __res; \
 > to:
 > __res_save = __res; \
 > errno = __res_save; \

 > I'm not sure that's the best/cleanest solution, but it does have the benefit
 > that when errno is a simple assignment (as is the case for the kernel), the
 > compiler optimizes out the additional assignment.


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?

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

<Prev in Thread] Current Thread [Next in Thread>