SEO

In SPARC systems, what conventions apply to the use og the register %g7?

For example, under Solaris 10 (or under the libc that comes with it), the
lmutex_unlock function starts off like this:

lmutex_unlock: save %sp, -96, %sp
lmutex_unlock+4: ld [%g7 + 84], %l2
lmutex_unlock+8: sethi %hi(0x1000), %i5
lmutex_unlock+0xc: add %i5, 132, %i1
lmutex_unlock+0x10: ld [%l2 + %i1], %l7
lmutex_unlock+0x14: tst %l7

where it is evident that %g7 is a globally understood register (presumably
pointing to some globally known collection of variables).

And for that matter, what is lmutex_unlock supposed to do; there is no man
page for it? All I know is that it is called by brk. And in Solaris 7, brk
was a much smaller beast that never called lmutex_unlock.

And I have observed that even my somewhat ancient Sun C compiler never
seems to make use of %g7.

OTOH, I have another compiler, nothing to do with Sun, that is not aware
of %g7 being reserved for anything. So as a result I have a program that
worked fine under Solaris 7, bur breaks in Solaris 10.

So what is going on?

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

On Thu, 2 Aug 2007 21:13:06 GMT "Charles Lindsey" <chl@clerew.man.ac.uk> wrote:
> In SPARC systems, what conventions apply to the use og the register %g7?

google for [sparc g7] returns

http://developers.sun.com/solaris/ar...parcv9abi.html

> OTOH, I have another compiler, nothing to do with Sun, that is not aware
> of %g7 being reserved for anything.

That compiler is [apparently] broken.

-frank

"Charles Lindsey" wrote:

> In SPARC systems, what conventions apply to the use og the register %g7?
>
> For example, under Solaris 10 (or under the libc that comes with it), the
> lmutex_unlock function starts off like this:
[...]
> where it is evident that %g7 is a globally understood register (presumably
> pointing to some globally known collection of variables).
[...]
> And I have observed that even my somewhat ancient Sun C compiler never
> seems to make use of %g7.
>
> OTOH, I have another compiler, nothing to do with Sun, that is not aware
> of %g7 being reserved for anything. So as a result I have a program that
> worked fine under Solaris 7, bur breaks in Solaris 10.

This blog post should answer all your questions:

http://blogs.sun.com/morganh/entry/a...king_the_rules

Marc wrote:
> "Charles Lindsey" wrote:
>
>
>>In SPARC systems, what conventions apply to the use og the register %g7?
>>
>>For example, under Solaris 10 (or under the libc that comes with it), the
>>lmutex_unlock function starts off like this:
>
> [...]
>
>>where it is evident that %g7 is a globally understood register (presumably
>>pointing to some globally known collection of variables).
>
> [...]
>
>>And I have observed that even my somewhat ancient Sun C compiler never
>>seems to make use of %g7.
>>
>>OTOH, I have another compiler, nothing to do with Sun, that is not aware
>>of %g7 being reserved for anything. So as a result I have a program that
>>worked fine under Solaris 7, bur breaks in Solaris 10.
>
>
> This blog post should answer all your questions:
>
> http://blogs.sun.com/morganh/entry/a...king_the_rules
>

The question it fails to answer is WHERE IS THIS DOCUMENTED! I'm not
personally concerned because the likelihood of my doing any assembler
language programming is just about zero! Still, it's reasonable to
expect this restriction to be documented and documented in a place where
it will be found by anyone doing SPARC assembler language programming.

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>> This blog post should answer all your questions:
>>
>> http://blogs.sun.com/morganh/entry/a...king_the_rules
>>

>The question it fails to answer is WHERE IS THIS DOCUMENTED! I'm not
>personally concerned because the likelihood of my doing any assembler
>language programming is just about zero! Still, it's reasonable to
>expect this restriction to be documented and documented in a place where
>it will be found by anyone doing SPARC assembler language programming.


You mean you want the page # of the document the blog references as
the official SPARC ABI?

Page 3-9 of the SPARC ABI documents which registers are reserved for what.

Specificly

%g7 %r7 global 7 (reserved for system)
%g6 %r6 global 6 (reserved for system)
%g5 %r5 global 5 (reserved for system)
%g4 %r4 global 4 (reserved for application)
%g3 %r3 global 3 (reserved for application)
%g2 %r2 global 2 (reserved for application)
%g1 %r1 global 1

In <f8uvod$1t6i$1@nef.ens.fr> Marc <marc.glisse@gmail.com> writes:

>"Charles Lindsey" wrote:

>> And I have observed that even my somewhat ancient Sun C compiler never
>> seems to make use of %g7.
>>
>> OTOH, I have another compiler, nothing to do with Sun, that is not aware
>> of %g7 being reserved for anything. So as a result I have a program that
>> worked fine under Solaris 7, bur breaks in Solaris 10.

>This blog post should answer all your questions:

>http://blogs.sun.com/morganh/entry/a...king_the_rules

Yes, that describes exactly the problem I have run into, and confirms that
it only arises in Solaris 10. Apparently, all processes are now considered
to be multi-threaded (and hence reserve %g7), and single-threaded
processes are not supposed to notice the difference (and indeed %g7 had
always been reserved for some unspecified 'system' use). It looks as
though %g6 could also produce similar problems.

The compiler that caused the problem was the Amsterdam Compiler Kit, which
is ancient and unmaintained, and was in any case never intended for
multi-threaded applications. So it seems I will have to do a little
maintenance of it myself :-( .

--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl
Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5