Re: [microblaze-uclinux] [patch] errno corruption

[David McCullough <davidm@xxxxxxxxxxxx>]

Jivin Yasushi SHOJI lays it down ...
> At Thu, 18 Mar 2004 15:32:25 +0900,
> I wrote:
> [...]
> > ok, here is my version of _sycall2
> > 
> > #define SYSCALL_CLOBBERS	"r3", "r4", "r11", "r12", "r17"
> > 
> > #define _syscall2(type, name, type1, arg1, type2, arg2)                 \
> > type name (type1 arg1, type2 arg2)                                      \
> > {                                                                       \
> >         register long __r5 __asm__ ("r5") = arg1;                       \
> >         register long __r6 __asm__ ("r6") = arg2;                       \

Originally I mentioned that you should avoid the above.  Here is the
comment from the gcc info pages:

   Defining such a register variable does not reserve the register; it
   remains available for other uses in places where flow control determines
   the variable's value is not live.  However, these registers are made
   unavailable for use in the reload pass; excessive use of this feature
   leaves the compiler too few available registers to compile certain
   functions.

   This option does not guarantee that GCC will generate code that has
   this variable in the register you specify at all times.  You may not
   code an explicit reference to this register in an `asm' statement and
   assume it will always refer to this variable.

The real trouble with unistd.h is that the syscalls are done as macros
and not inline functions.  This means the can be included into the
middle of some C code,  and at the point the optimiser may move your
declarations away from the asm,  leaving the possibility for the value
in the register to not be preserved and break your system call.

That said,  99% of archs get away with it.  m68k still does.  The
trouble is the newer the compiler the more likely it is to break, and
I have see this problem happen under m68k,  especially in code trying to
save a few bytes on system calls.  When it happens,  expect a very long
debug session and "Doh!" at the end ;-)

I know if may not be as efficient (m68k has the same problem) but I
believe it is the only way to guarantee it is correct,

Cheers,
Davidm

-- 
David McCullough, davidm@snapgear.com  Ph:+61 7 34352815 http://www.SnapGear.com
Custom Embedded Solutions + Security   Fx:+61 7 38913630 http://www.uCdot.org
___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/