NetBSD Problem Report #4029

Received: (qmail 4152 invoked from network); 23 Aug 1997 20:38:09 -0000
Message-Id: <199708232038.WAA08099@ulysses.df.lth.se>
Date: Sat, 23 Aug 1997 22:38:03 +0200 (CEST)
From: Krister Walfridsson <cato@ulysses.df.lth.se>
Reply-To: cato@ulysses.df.lth.se
To: gnats-bugs@gnats.netbsd.org
Subject: Register usage doesn't comply with SPARC ABI
X-Send-Pr-Version: 3.95

>Number:         4029
>Category:       port-sparc
>Synopsis:       Register usage doesn't comply with SPARC ABI
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    uwe
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Sat Aug 23 13:50:01 +0000 1997
>Closed-Date:    Sun Apr 22 19:21:38 +0000 2012
>Last-Modified:  Sun Apr 22 19:21:38 +0000 2012
>Originator:     Krister Walfridsson
>Release:        NetBSD-current Aug 15 1997
>Organization:

>Environment:

System: NetBSD ulysses 1.2G NetBSD 1.2G (KWA) #0: Fri Aug 15 20:36:02 CEST 1997 cato@ulysses:/usr/src/sys/arch/sparc/compile/KWA sparc


>Description:
Modern languages usually have runtime systems which stores some pointers
in global registers, and compilers I have encountered usually likes to store
those in %g3 and %g4. Unfortunally does NetBSD destroy them (at least %g3)
in linbrary calls.

The SPARC Architecture Manual (Version 8) says

   The convention used by the SPARC Application Binary Interface (ABI)
   is that %g1 is assumed to be volatile across procedure calls,
   %g2 ... %g4 are reserved for use by the application program (for
   example, as global register variables), and %g5 ... %g7 are assumed
   to be nonvolatile and reserved for (as-yet-undefined) use by the
   execution environment.

...so we shouldn't use %g2-%g4 in library code. %g2 are used in function
calls, and I don't know if we can change it without breaking anything,
but %g3 and %g4 aren't used (more than temporary registers for gcc) so
it is easy to keep the value in them across library calls.

>How-To-Repeat:
Try to run the following program

.text
        .align 8
LC0:
        .ascii "%d\12\0"
        .align 4
        .global _main
_main:
        save %sp,-104,%sp

        mov 23,%g3

        sethi %hi(LC0),%o0
        or %o0,%lo(LC0),%o0
        call _printf,0
        mov %g3,%o1

        sethi %hi(LC0),%o0
        or %o0,%lo(LC0),%o0
        call _printf,0
        mov %g3,%o1

        ret
        restore

When I run this, I get something like

   bash$ ./a.out
   23
   50331648

i.e. printf destroys %g3

>Fix:
Use the flag '-mno-app-regs' when compiling libraries

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->port-sparc-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Dec 28 09:30:07 PST 1998 
Responsible-Changed-Why:  
This PR is the responsibility of the portmaster, 
not the GNATS database administrator. 
State-Changed-From-To: open->feedback 
State-Changed-By: martin 
State-Changed-When: Tue Aug 13 01:39:50 PDT 2002 
State-Changed-Why:  
This seems to be fixed with the new toolchain (and/or the ELF switch). 

This version of the test program seems to work for me: 
.text 
.align 8 
LC0: 
.ascii "%d120" 
.align 4 
.global main 
main: 
save %sp,-104,%sp 

mov 23,%g3 

sethi %hi(LC0),%o0 
or %o0,%lo(LC0),%o0 
call printf,0 
mov %g3,%o1 

sethi %hi(LC0),%o0 
or %o0,%lo(LC0),%o0 
call printf,0 
mov %g3,%o1 

ret 
restore 

Is it OK to close this PR now? 
State-Changed-From-To: feedback->closed 
State-Changed-By: martin 
State-Changed-When: Tue Aug 13 02:00:44 PDT 2002 
State-Changed-Why:  
Resolved when we switched sparc to ELF. 
State-Changed-From-To: closed->open 
State-Changed-By: uwe 
State-Changed-When: Wed Apr 9 14:40:46 PDT 2003 
State-Changed-Why:  
The PR was closed incorrectly. I'll add the evaluation shortly. 


Responsible-Changed-From-To: port-sparc-maintainer->uwe 
Responsible-Changed-By: uwe 
Responsible-Changed-When: Wed Apr 9 14:40:46 PDT 2003 
Responsible-Changed-Why:  
I'll handle it.  I already have the fix, it just needs a little polishing. 

From: "Valeriy E. Ushakov" <uwe@ptc.spbu.ru>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: port-sparc/4029
Date: Thu, 10 Apr 2003 01:58:04 +0400

 By default gcc uses -mapp-regs, i.e. it is configured to compile
 "applications", not "system software".  We should compile system
 libraries (and, probably, X libraries) with:

     -mno-app-regs -fcall-used-g5 -fcall-used-g7

 Note that %g6 is kept reserved, I'm told that we plan to use it as the
 thread-self register.

 We also need some trivial tweaks to the hand-written assembler
 routines that use "app" registers to use "system" registers instead.

 Our syscalls use %g2 (SYSCALL_G2RFLAG), but, fortunately, they can
 also use %g7 (SYSCALL_G7RFLAG).  The latter is currently marked as
 deprecated, we just need to make the g2 deprecated instead, no kernel
 changes are necessary.

 -uwe
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/4029
Date: Thu, 2 Feb 2012 23:29:40 +0100

 This got complicated by TLS reserving %g7 as thread-self register, so now
 we use %g5 for syscalls. What library CFLAGS do we need to fix to finaly
 close this now?

 Martin

From: "Valeriy E. Ushakov" <uwe@stderr.spb.ru>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/4029
Date: Fri, 3 Feb 2012 02:40:15 +0400

 On Thu, Feb 02, 2012 at 22:30:04 +0000, Martin Husemann wrote:

 > This got complicated by TLS reserving %g7 as thread-self register, so now
 > we use %g5 for syscalls. What library CFLAGS do we need to fix to finaly
 > close this now?

 The point is moot.  What exactly is "system software" as applied to
 netbsd, given that we don't conform to SVR4.  If X11 comes from
 pkgsrc, should we adjust pkgsrc to compile it as "system software"?
 Etc, etc...

 May be we can just give up and close this?

 -uwe

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 22 Apr 2012 19:21:38 +0000
State-Changed-Why:
This gets discussed occasionally from time to time, and every time the
rough conclusion is that it's bogus. However, we never seem to manage
to quite get as far as firmly deciding to give up on it.

Let's do that. *punt*


>Unformatted:

Home	PR Database Search