[Buildroot] Buildroot Compile Errors for SH4

Paul Mundt lethal at linux-sh.org
Tue Apr 10 20:17:36 UTC 2007


On Tue, Apr 10, 2007 at 09:58:02PM +0200, Bernhard Fischer wrote:
> On Tue, Apr 10, 2007 at 03:43:32PM -0400, Bill Traynor wrote:
> >On 4/10/07, Bill Traynor <btraynor at gmail.com> wrote:
> >> CC libc/sysdeps/linux/sh/syscall.os
> >> libc/sysdeps/linux/sh/syscall.c:11: error: conflicting types for 'syscall'
> >> ./include/unistd.h:1016: error: previous declaration of 'syscall' was here
> >
> >So the offending code is:
> >
> >syscall.c
> >long syscall(long sysnum,
> >                         long arg1, long arg2, long arg3,
> >                         long arg4, long arg5, long arg6)
> >{
> >register long __sc3 __asm__ ("r3") = sysnum;
> >register long __sc4 __asm__ ("r4") = (long) arg1;
> >register long __sc5 __asm__ ("r5") = (long) arg2;
> >register long __sc6 __asm__ ("r6") = (long) arg3;
> >register long __sc7 __asm__ ("r7") = (long) arg4;
> >register long __sc0 __asm__ ("r0") = (long) arg5;
> >register long __sc1 __asm__ ("r1") = (long) arg6;
> >__asm__ __volatile__ (
> >        "trapa %1"
> >        : "=z" (__sc0) \
> >        : "i" (__SH_SYSCALL_TRAP_BASE + 6),
> >          "0" (__sc0), "r" (__sc4), "r" (__sc5), "r" (__sc6), "r" (__sc7), \
> >          "r" (__sc3), "r" (__sc1) \
> >        : "memory" );
> >__syscall_return(long,__sc0);
> >}
> >
> >and unistd.h:
> >extern long int syscall (long int __sysno, ...) __THROW;
> >
> >The question now is how to fix this for SH.

This is the syscall() definition in the __USE_MISC case, and it's
certainly not limited to SH. There are hardly any users that implement
syscall() using varargs, so this will break other places as well.

We could convert syscall() to use varargs, though we'd have to take the
length of the arglist to add to __SH_SYSCALL_TRAP_BASE, though as
_syscall6() is the worst case, so perhaps that's fine in the general
case.

I suppose the question is why some are using varargs and others aren't. I
don't mind changing it if there's a consensus. In any event, this will
hit pretty much all of the other architectures, too..



More information about the uClibc mailing list