The April release of LTP is now on SourceForge.
LTP-20050405
- Fixed '-d' option to runltp.sh
- Added optional ltp (fivextra) extended testsuite
- Added digital signiture testcases from the security team
- Applied patch from Gernot Payer to fix, mincore01, shmget02, capset02
- Applied suggested check from Carl van_Schaik to clone02.
- Added seLinux testsuite from security team and Stephen Smalley.
- Added NFS cthon04 tests needed files.
Linux Test Project
Linux Technology Center
IBM Corporation
Internet E-Mail : [email protected]
IBM, 11501 Burnet Rd, Austin, TX 78758
Phone (512) 838-1356 - T/L 678-1356 - Bldg. 908/1C005
Austin, TX.
Marty Ridgeway <[email protected]> wrote:
>
> The April release of LTP is now on SourceForge.
>
> LTP-20050405
It seems to have an x86ism in it which causes the compile to fail on ppc64:
socketcall01.c: In function `socketcall':
socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list
#ifndef _syscall2
#include <linux/unistd.h>
#endif
#include "test.h"
#include "usctest.h"
char *TCID = "socketcall01"; /* Test program identifier. */
#ifdef __NR_socketcall
_syscall2(int ,socketcall ,int ,call, unsigned long *, args);
Andrew Morton wrote:
>> LTP-20050405
>
> It seems to have an x86ism in it which causes the compile to fail on ppc64:
>
> socketcall01.c: In function `socketcall':
> socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list
That might be a problem with your toolchain.
Other mentions of that error message on Google
suggest that it's due to a kernel header problem.
I bet your toolchain uses kernel headers from 2.4.21 or earlier...
check includes/asm-ppc64/unistd.h to see if it's got the
line
/* On powerpc a system call basically clobbers the same registers like a
in it. If not, it may be missing the patch mentioned below.
See
http://ozlabs.org/pipermail/linuxppc64-dev/2003-April/000211.html
http://ozlabs.org/pipermail/linuxppc-dev/2002-October/014492.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9379
http://www.hu.kernel.org/pub/linux/kernel/v2.4/snapshots/incr/patch-2.4.22-bk57-bk58
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Wed, 2005-04-06 at 08:05 -0700, Dan Kegel wrote:
> Andrew Morton wrote:
> >> LTP-20050405
> >
> > It seems to have an x86ism in it which causes the compile to fail on ppc64:
> >
> > socketcall01.c: In function `socketcall':
> > socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list
>
> That might be a problem with your toolchain.
I wonder why ltp doesn't just use the normal syscall() macro/functions
but instead insists on using stuff from kernel headers...
Andrew Morton writes:
> Marty Ridgeway <[email protected]> wrote:
> >
> > The April release of LTP is now on SourceForge.
> >
> > LTP-20050405
>
> It seems to have an x86ism in it which causes the compile to fail on ppc64:
Looks to me like gcc is objecting to our (ppc64's) _syscall2
definition; Alan Modra (cc'd) can probably say what we're doing wrong.
> socketcall01.c: In function `socketcall':
> socketcall01.c:80: error: asm-specifier for variable `__sc_4' conflicts with asm clobber list
>
>
>
>
> #ifndef _syscall2
> #include <linux/unistd.h>
> #endif
>
> #include "test.h"
> #include "usctest.h"
>
> char *TCID = "socketcall01"; /* Test program identifier. */
> #ifdef __NR_socketcall
>
> _syscall2(int ,socketcall ,int ,call, unsigned long *, args);
Here is the definition of _syscall2 (for Alan):
#define __syscall_nr(nr, type, name, args...) \
unsigned long __sc_ret, __sc_err; \
{ \
register unsigned long __sc_0 __asm__ ("r0"); \
register unsigned long __sc_3 __asm__ ("r3"); \
register unsigned long __sc_4 __asm__ ("r4"); \
register unsigned long __sc_5 __asm__ ("r5"); \
register unsigned long __sc_6 __asm__ ("r6"); \
register unsigned long __sc_7 __asm__ ("r7"); \
register unsigned long __sc_8 __asm__ ("r8"); \
\
__sc_loadargs_##nr(name, args); \
__asm__ __volatile__ \
("sc \n\t" \
"mfcr %0 " \
: "=&r" (__sc_0), \
"=&r" (__sc_3), "=&r" (__sc_4), \
"=&r" (__sc_5), "=&r" (__sc_6), \
"=&r" (__sc_7), "=&r" (__sc_8) \
: __sc_asm_input_##nr \
: "cr0", "ctr", "memory", \
"r9", "r10","r11", "r12"); \
__sc_ret = __sc_3; \
__sc_err = __sc_0; \
} \
if (__sc_err & 0x10000000) \
{ \
errno = __sc_ret; \
__sc_ret = -1; \
} \
return (type) __sc_ret
#define __sc_loadargs_0(name, dummy...) \
__sc_0 = __NR_##name
#define __sc_loadargs_1(name, arg1) \
__sc_loadargs_0(name); \
__sc_3 = (unsigned long) (arg1)
#define __sc_loadargs_2(name, arg1, arg2) \
__sc_loadargs_1(name, arg1); \
__sc_4 = (unsigned long) (arg2)
#define __sc_loadargs_3(name, arg1, arg2, arg3) \
__sc_loadargs_2(name, arg1, arg2); \
__sc_5 = (unsigned long) (arg3)
#define __sc_loadargs_4(name, arg1, arg2, arg3, arg4) \
__sc_loadargs_3(name, arg1, arg2, arg3); \
__sc_6 = (unsigned long) (arg4)
#define __sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5) \
__sc_loadargs_4(name, arg1, arg2, arg3, arg4); \
__sc_7 = (unsigned long) (arg5)
#define __sc_loadargs_6(name, arg1, arg2, arg3, arg4, arg5, arg6) \
__sc_loadargs_5(name, arg1, arg2, arg3, arg4, arg5); \
__sc_8 = (unsigned long) (arg6)
#define __sc_asm_input_0 "0" (__sc_0)
#define __sc_asm_input_1 __sc_asm_input_0, "1" (__sc_3)
#define __sc_asm_input_2 __sc_asm_input_1, "2" (__sc_4)
#define __sc_asm_input_3 __sc_asm_input_2, "3" (__sc_5)
#define __sc_asm_input_4 __sc_asm_input_3, "4" (__sc_6)
#define __sc_asm_input_5 __sc_asm_input_4, "5" (__sc_7)
#define __sc_asm_input_6 __sc_asm_input_5, "6" (__sc_8)
#define _syscall0(type,name) \
type name(void) \
{ \
__syscall_nr(0, type, name); \
}
#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
__syscall_nr(1, type, name, arg1); \
}
#define _syscall2(type,name,type1,arg1,type2,arg2) \
type name(type1 arg1, type2 arg2) \
{ \
__syscall_nr(2, type, name, arg1, arg2); \
}
Paul Mackerras wrote:
> if (__sc_err & 0x10000000) \
> { \
> errno = __sc_ret; \
> __sc_ret = -1; \
> } \
If you're messing with that code anyways, any chance of changing the
assignment to "__sc_ret = -1UL;", since __sc_ret is of type unsigned long?
Chris
On Thu, Apr 07, 2005 at 10:52:01AM +1000, Paul Mackerras wrote:
> Looks to me like gcc is objecting to our (ppc64's) _syscall2
> definition; Alan Modra (cc'd) can probably say what we're doing wrong.
I can't spot anything wrong. Take a look at preprocessed source.
--
Alan Modra
IBM OzLabs - Linux Technology Centre