[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uclibc
Subject:    Re: [PATCH] MIPS64 N64 fork is broken
From:       Steve Ellcey <sellcey () mips ! com>
Date:       2014-02-05 0:13:06
Message-ID: 1391559186.3022.293.camel () ubuntu-sellcey
[Download RAW message or body]


On Tue, Feb 4, 2014 at 00:38:30 -0500, Rich Felker wrote:
> On Sat, Dec 21, 2013 at 01:18:29PM +0100, Waldemar Brodkorb wrote:
> > +#undef internal_syscall5
> > +#define internal_syscall5(ncs_init, cs_init, input, err, arg1, arg2, arg3, arg4, arg5) \
> > +({ 									\
> > +	long _sys_result;						\
> > +									\
> > +	{								\
> > +	register long __v0 __asm__("$2") ncs_init;			\
> > +	register long __a0 __asm__("$4") = (long) arg1; 	\
> > +	register long __a1 __asm__("$5") = (long) arg2; 	\
> > +	register long __a2 __asm__("$6") = (long) arg3; 	\
> > +	register long __a3 __asm__("$7") = (long) arg4; 	\
> > +	register long __a4 __asm__("$8") = (long) arg5; 	\
> > +	__asm__ __volatile__ ( 						\
> > +	".set\tnoreorder\n\t" 						\
> > +	cs_init								\
> > +	"syscall\n\t" 							\
> > +	".set\treorder" 						\
> 
> I seem to recall MIPS assembler having push/pop directives for
> settings like this. Wouldn't it be better to use them to restore the
> old setting of reorder rather than forcing it on after asm, so as not
> to assume the compiler had, and wants, reorder on?
> 
> Rich

You are right, MIPS does have a '.set push' and '.set pop' that should
probably be used here.  Before fixing that in all the internal_syscall*
macros though I wonder if we should clean up the duplicate definitions.
Right now there are definitions of internal_syscall[01234567] in both
libc/sysdeps/linux/mips/bits/syscalls.h and
libc/sysdeps/linux/mips/sysdep.h.  I don't know the history of why there
are definitions in both places but I am currently testing a patch where
I removed all the definitions of internal_syscall* macros,
INTERNAL_SYSCALL* macros, and the __SYSCALL_CLOBBERS macro from
libc/sysdeps/linux/mips/sysdep.h to see if everything still builds (so
far so good).  If anyone knows why this would be the wrong thing to do I
would like to hear from them.

Steve Ellcey
sellcey@mips.com


_______________________________________________
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
[prev in list] [next in list] [prev in thread] [next in thread]