Subject: Re: port-m68k/37631: m68k libc broken
To: None <port-m68k-maintainer@netbsd.org, gnats-admin@netbsd.org,>
From: Ignatios Souvatzis <is@netbsd.org>
List: netbsd-bugs
Date: 12/28/2007 15:30:02
The following reply was made to PR port-m68k/37631; it has been noted by GNATS.

From: Ignatios Souvatzis <is@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: port-m68k-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org, martin@duskware.de
Subject: Re: port-m68k/37631: m68k libc broken
Date: Fri, 28 Dec 2007 16:26:21 +0100

 On Fri, Dec 28, 2007 at 02:45:02PM +0000, Martin Husemann wrote:
 > The following reply was made to PR port-m68k/37631; it has been noted by GNATS.
 > 
 > From: Martin Husemann <martin@duskware.de>
 > To: gnats-bugs@NetBSD.org
 > Cc: 
 > Subject: Re: port-m68k/37631: m68k libc broken
 > Date: Fri, 28 Dec 2007 15:44:08 +0100
 > 
 >  --AhhlLboLdkugWU4S
 >  Content-Type: text/plain; charset=us-ascii
 >  Content-Disposition: inline
 >  
 >  I was wrong: looking at the libc object code all looked fine to me.
 >  So I looked at the syscall code in the kernel and found the patch below,
 >  wich fixes this problem for me. The old libc code just papered over it.
 >  
 >  Is this ok to commit?
 >  
 >  Martin
 >  
 >  --AhhlLboLdkugWU4S
 >  Content-Type: text/plain; charset=us-ascii
 >  Content-Disposition: attachment; filename=patch
 >  
 >  Index: m68k_syscall.c
 >  ===================================================================
 >  RCS file: /cvsroot/src/sys/arch/m68k/m68k/m68k_syscall.c,v
 >  retrieving revision 1.30
 >  diff -c -u -r1.30 m68k_syscall.c
 >  --- m68k_syscall.c	17 Oct 2007 19:55:12 -0000	1.30
 >  +++ m68k_syscall.c	28 Dec 2007 14:41:35 -0000
 >  @@ -288,6 +288,8 @@
 >   			if (p->p_emul != &emul_netbsd_aoutm68k)
 >   				frame->f_regs[A0] = rval[0];
 >   		}
 >  +#else
 >  +		frame->f_regs[A0] = rval[0];
 >   #endif
 >   		break;
 
 Hm... I'm not Klaus Klein, but yes, for m68kelf (at least), C functions
 return pointers returned in A0 (possibly in addition to D0).
 
 Whether to enforce this at the syscall interface or at the libc
 interface is probably a matter of taste, and your way we can't
 forget it.
 
 Uh... don't forget syscall_fancy (in addition to syscall_plain).
 
 	-is