From Craig.Mohrman at eng.sun.com  Tue Apr  5 12:55:43 2005
From: Craig.Mohrman at eng.sun.com (Craig Mohrman)
Date: Tue, 5 Apr 2005 12:55:43 -0700 (PDT)
Subject: [gcc] 9. libgcc (64-bit arithmetic using 32-bit registers) 
Message-ID: <200504051955.j35Jth64416365@jurassic.eng.sun.com>

Status:

x86 compiles.  But does it work?
	Using the cw in this source tree, one only needs the following
	change to fix a warning and both ia32 and amd64 compile just fine.
	
	usr/src/lib/libc/port/threads/assfail.c

------- assfail.c -------
335c335
<       ultos((uint64_t)self, 16, buf + strlen(buf));
---
>       ultos((uint64_t)(uintptr_t)self, 16, buf + strlen(buf));
337c337
<       ultos((uint64_t)lwpid, 10, buf + strlen(buf));
---
>       ultos((uint64_t)(uintptr_t)lwpid, 10, buf + strlen(buf));

	Both the SOS8 and gcc compiles and lints are clean.
	Does the gcc compiled code work?
	Dunno.  That's tomorrow project.
	
	And I don't need to link with libgcc.  The amd64 work fixed
	all those holes.
	
SPARC uses libgcc.  Awaiting inlines for complete compile.
	For SPARC 32-bit compiles I'm linking with libgcc to pick up
	__lshrdi3, __divdi3, __floatdidf, etc.
	The remaining missing symbols are coming from inlines so
	I'm waiting for Andrei's translations of those babies.
	
	SPARCv9 does not need libgcc.  Just the inlines.

Keith?  Should I code review and putback my changes into onnv or
the OpenSolaris gate?

Tomorrow, wednesday, I'll load up my x86 libc's on a system and see
how well they work.

craig



From kritter at eng.sun.com  Tue Apr  5 12:56:42 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Tue, 05 Apr 2005 12:56:42 -0700
Subject: [gcc] Re: 9. libgcc (64-bit arithmetic using 32-bit registers)
In-Reply-To: <200504051955.j35Jth64416365@jurassic.eng.sun.com>
References: <200504051955.j35Jth64416365@jurassic.eng.sun.com>
Message-ID: <4252ED7A.5070807@eng.sun.com>

Thanks for the status Craig!

Andrei: How are the inlines coming along?

Thanks,

Karyn

Craig Mohrman wrote:
> Status:
> 
> x86 compiles.  But does it work?
> 	Using the cw in this source tree, one only needs the following
> 	change to fix a warning and both ia32 and amd64 compile just fine.
> 	
> 	usr/src/lib/libc/port/threads/assfail.c
> 
> ------- assfail.c -------
> 335c335
> <       ultos((uint64_t)self, 16, buf + strlen(buf));
> ---
> 
>>      ultos((uint64_t)(uintptr_t)self, 16, buf + strlen(buf));
> 
> 337c337
> <       ultos((uint64_t)lwpid, 10, buf + strlen(buf));
> ---
> 
>>      ultos((uint64_t)(uintptr_t)lwpid, 10, buf + strlen(buf));
> 
> 
> 	Both the SOS8 and gcc compiles and lints are clean.
> 	Does the gcc compiled code work?
> 	Dunno.  That's tomorrow project.
> 	
> 	And I don't need to link with libgcc.  The amd64 work fixed
> 	all those holes.
> 	
> SPARC uses libgcc.  Awaiting inlines for complete compile.
> 	For SPARC 32-bit compiles I'm linking with libgcc to pick up
> 	__lshrdi3, __divdi3, __floatdidf, etc.
> 	The remaining missing symbols are coming from inlines so
> 	I'm waiting for Andrei's translations of those babies.
> 	
> 	SPARCv9 does not need libgcc.  Just the inlines.
> 
> Keith?  Should I code review and putback my changes into onnv or
> the OpenSolaris gate?
> 
> Tomorrow, wednesday, I'll load up my x86 libc's on a system and see
> how well they work.
> 
> craig
> 


From mike_s at yavin.Eng.Sun.COM  Tue Apr  5 13:01:30 2005
From: mike_s at yavin.Eng.Sun.COM (Mike Sullivan)
Date: Tue, 5 Apr 2005 13:01:30 -0700 (PDT)
Subject: [gcc] Re: 9. libgcc (64-bit arithmetic using 32-bit registers)
Message-ID: <200504052001.j35K1U0s536853@yavin.Eng.Sun.COM>


gcc-compiled Intel kernel now boots. I'm afraid to bfu though.

>X-Original-To: gcc at opensolaris.org
>Delivered-To: gcc at opensolaris.org
>Date: Tue, 05 Apr 2005 12:56:42 -0700
>From: Karyn Ritter <kritter at eng.sun.com>
>To: Craig Mohrman <Craig.Mohrman at eng.sun.com>
>MIME-version: 1.0
>Content-transfer-encoding: 7BIT
>X-Accept-Language: en-us, en
>User-Agent: Mozilla Thunderbird 0.5 (X11/20040210)
>Cc: gcc at opensolaris.org, Linda.Bernal at sun.com
>Subject: [gcc] Re: 9. libgcc (64-bit arithmetic using 32-bit registers)
>X-BeenThere: gcc at opensolaris.org
>X-Mailman-Version: 2.1.4
>List-Id: GCC porting discussion <gcc.opensolaris.org>
>List-Unsubscribe: <https://www.opensolaris.org/mailman/listinfo/gcc>, 
<mailto:gcc-request at opensolaris.org?subject=unsubscribe>
>List-Archive: <https://www.opensolaris.org/pipermail/gcc>
>List-Post: <mailto:gcc at opensolaris.org>
>List-Help: <mailto:gcc-request at opensolaris.org?subject=help>
>List-Subscribe: <https://www.opensolaris.org/mailman/listinfo/gcc>, 
<mailto:gcc-request at opensolaris.org?subject=subscribe>
>
>Thanks for the status Craig!
>
>Andrei: How are the inlines coming along?
>
>Thanks,
>
>Karyn
>
>Craig Mohrman wrote:
>> Status:
>> 
>> x86 compiles.  But does it work?
>> 	Using the cw in this source tree, one only needs the following
>> 	change to fix a warning and both ia32 and amd64 compile just fine.
>> 	
>> 	usr/src/lib/libc/port/threads/assfail.c
>> 
>> ------- assfail.c -------
>> 335c335
>> <       ultos((uint64_t)self, 16, buf + strlen(buf));
>> ---
>> 
>>>      ultos((uint64_t)(uintptr_t)self, 16, buf + strlen(buf));
>> 
>> 337c337
>> <       ultos((uint64_t)lwpid, 10, buf + strlen(buf));
>> ---
>> 
>>>      ultos((uint64_t)(uintptr_t)lwpid, 10, buf + strlen(buf));
>> 
>> 
>> 	Both the SOS8 and gcc compiles and lints are clean.
>> 	Does the gcc compiled code work?
>> 	Dunno.  That's tomorrow project.
>> 	
>> 	And I don't need to link with libgcc.  The amd64 work fixed
>> 	all those holes.
>> 	
>> SPARC uses libgcc.  Awaiting inlines for complete compile.
>> 	For SPARC 32-bit compiles I'm linking with libgcc to pick up
>> 	__lshrdi3, __divdi3, __floatdidf, etc.
>> 	The remaining missing symbols are coming from inlines so
>> 	I'm waiting for Andrei's translations of those babies.
>> 	
>> 	SPARCv9 does not need libgcc.  Just the inlines.
>> 
>> Keith?  Should I code review and putback my changes into onnv or
>> the OpenSolaris gate?
>> 
>> Tomorrow, wednesday, I'll load up my x86 libc's on a system and see
>> how well they work.
>> 
>> craig
>> 
>_______________________________________________
>gcc mailing list
>gcc at opensolaris.org
>https://www.opensolaris.org/mailman/listinfo/gcc



From keith.wesolowski at sun.com  Tue Apr  5 13:07:46 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Tue, 5 Apr 2005 13:07:46 -0700
Subject: [gcc] 9. libgcc (64-bit arithmetic using 32-bit registers)
In-Reply-To: <200504051955.j35Jth64416365@jurassic.eng.sun.com>
References: <200504051955.j35Jth64416365@jurassic.eng.sun.com>
Message-ID: <20050405200746.GA1566@sun.com>

On Tue, Apr 05, 2005 at 12:55:43PM -0700, Craig Mohrman wrote:

> 	And I don't need to link with libgcc.  The amd64 work fixed
> 	all those holes.

Yes, Mike and I were discussing that yesterday.  This is good news,
since it means that having these functions in libc is presumably
acceptable (or, more precisely, that we aren't making things any
worse).

> SPARC uses libgcc.  Awaiting inlines for complete compile.
> 	For SPARC 32-bit compiles I'm linking with libgcc to pick up
> 	__lshrdi3, __divdi3, __floatdidf, etc.
> 	The remaining missing symbols are coming from inlines so
> 	I'm waiting for Andrei's translations of those babies.

I don't think linking in libgcc is the right approach.  Since x86 has
these functions in libc and the kernel, we ought to have them there
for sparc also.  The problem they solve is the same.  If we decide
that linking in libgcc is the right fix, we should remove the x86
functions and use libgcc there as well.

Also, are you linking in the static or shared libgcc?  Definitely
linking the shared one is undesirable; it's not always installed.

> 	SPARCv9 does not need libgcc.  Just the inlines.

That makes sense; 64-bit targets would have no use for these
functions.

> Keith?  Should I code review and putback my changes into onnv or
> the OpenSolaris gate?

The assfail bug fix is definitely onnv material.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From keith.wesolowski at sun.com  Tue Apr  5 13:25:17 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Tue, 5 Apr 2005 13:25:17 -0700
Subject: [gcc] Re: 9. libgcc (64-bit arithmetic using 32-bit registers)
In-Reply-To: <200504052001.j35K1U0s536853@yavin.Eng.Sun.COM>
References: <200504052001.j35K1U0s536853@yavin.Eng.Sun.COM>
Message-ID: <20050405202517.GB1566@sun.com>

On Tue, Apr 05, 2005 at 01:01:30PM -0700, Mike Sullivan wrote:

> gcc-compiled Intel kernel now boots. I'm afraid to bfu though.

With lots of hacks, SPARC can boot but not function.  The major issues
are:

1. I'm using a hacked compiler to provide ctfconvert with direct DWARF
strings.  My original workaround causes ctfmerge to fail.  Matt
Simmons is still investigating the proper fix for this (or perhaps the
compiler change will end up being the fix).

2. gcc builds krtld_boot.o with GOT references.  Since there is no GOT
when this code runs, you get a memory not aligned error before the
banner.  We have a flag in DevPro added just for this purpose,
-Wu,-no_got_reloc, in DevPro but gcc has no corresponding flag.  My
workaround for now is to use a krtld built with the usual compiler,
and I'm exploring various other flags to avoid the optimization in
question.  We may need to get a similar flag added to gcc.

3. Our linker doesn't tolerate R_SPARC_{8,16,32} relocations in
objects being linked into 64-bit shared libraries.  These are
converted to R_SPARC_RELATIVE relocations which require 8-byte
alignment, even though the originals require smaller alignments.  This
happens when gcc generates jump tables in the abs32 code model,
something like:

.LL100:
	some code...
.LL101:
	some code...

.LL500:
	.word	.LL100
	.word	.LL101

...

	sethi	%hi(.LL500), %g4
	or	%g4, %lo(.LL500), %g4
	lduw	[%g4+%g1], %g5
	jmp	%g5
	 nop

where %g1 is set to select the appropriate jump target from the table.

The linker behaviour is arguably correct; a shared library with this
kind of code (in fact, almost any using the abs32 code model) will not
work.  However, the shared libraries in question are libgenunix.so and
similar used to resolve symbols when building other kernel modules.
They are never run at all and in fact are not even delivered.  Mike
Walker has made some suggestions and we're investigating the correct
course of action.

4. forthdebug (not included in OpenSolaris) uses the stabs tool, which
in turn relies on a compiler generating stabs debug data in a
particular format.  gcc doesn't provide this, so I've converted this
to use ctfstabs instead.  ctfstabs understands DWARF debugging data,
which gcc does provide, and also provides better checking of the forth
template files.  As a result, I've uncovered a few other bugs in
ctfstabs that we'll need to fix (specifically, it ignores parts of the
template that tell it which structure members to output and the format
to use when doing so).

With all this, I can get all the way to the login prompt, but missing
symbols prevent the ip module from loading, which is pretty much a
showstopper.  More to come.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From schilling at fokus.fraunhofer.de  Tue Apr  5 16:30:02 2005
From: schilling at fokus.fraunhofer.de (Joerg Schilling)
Date: Wed, 06 Apr 2005 01:30:02 +0200
Subject: [gcc] 9. libgcc (64-bit arithmetic using 32-bit registers)
In-Reply-To: <20050405200746.GA1566@sun.com>
References: <200504051955.j35Jth64416365@jurassic.eng.sun.com>
	<20050405200746.GA1566@sun.com>
Message-ID: <42531F7A.nail66Z213XSW@burner>

Keith M Wesolowski <keith.wesolowski at sun.com> wrote:

> Also, are you linking in the static or shared libgcc?  Definitely
> linking the shared one is undesirable; it's not always installed.

Not having a dynamic libgcc was always a bug before it has been
made possible.

Note that you will get into problems with dlopen()'d libraries if
there is no danamic libgcc

J?rg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
       js at cs.tu-berlin.de		(uni)  
       schilling at fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily


From keith.wesolowski at sun.com  Tue Apr  5 21:25:52 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Tue, 5 Apr 2005 21:25:52 -0700
Subject: [gcc] SPARC/gcc kernel status
Message-ID: <20050406042552.GA16313@sun.com>

The gcc-built SPARC kernel can boot, with the following two
exceptions:

1. krtld is still busted as described previously.

2. The md5 module doesn't work because we need to implement the
load_little_32 inline.  This module is depended upon by almost
everything, and ultimately the failure prevents ip from loading.

Replacing just these two modules with their standard versions, I can
boot, log in, and use the network.  There are a large number of
warnings from fbt at startup of the form:

NOTICE: strange leaf jmpl/call delay at 7b277b48

and

NOTICE: cannot instrument relock_skip_pid: begins with non-ba CTI

I'll start tracking these down tomorrow.  I should note that dtrace is
at least partially functional even with these warnings.  Presumably
the problem is either more odd jump table entries or an unusual gcc
instruction pattern.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From kritter at eng.sun.com  Wed Apr  6 09:44:49 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Wed, 06 Apr 2005 09:44:49 -0700
Subject: [gcc] Re: 9. libgcc (64-bit arithmetic using 32-bit registers)
In-Reply-To: <20050405202517.GB1566@sun.com>
References: <200504052001.j35K1U0s536853@yavin.Eng.Sun.COM>
	<20050405202517.GB1566@sun.com>
Message-ID: <42541201.2050508@eng.sun.com>

This is great news, Keith -- thanks for sharing!

- Karyn

Keith M Wesolowski wrote:
> On Tue, Apr 05, 2005 at 01:01:30PM -0700, Mike Sullivan wrote:
> 
> 
>>gcc-compiled Intel kernel now boots. I'm afraid to bfu though.
> 
> 
> With lots of hacks, SPARC can boot but not function.  The major issues
> are:
> 
> 1. I'm using a hacked compiler to provide ctfconvert with direct DWARF
> strings.  My original workaround causes ctfmerge to fail.  Matt
> Simmons is still investigating the proper fix for this (or perhaps the
> compiler change will end up being the fix).
> 
> 2. gcc builds krtld_boot.o with GOT references.  Since there is no GOT
> when this code runs, you get a memory not aligned error before the
> banner.  We have a flag in DevPro added just for this purpose,
> -Wu,-no_got_reloc, in DevPro but gcc has no corresponding flag.  My
> workaround for now is to use a krtld built with the usual compiler,
> and I'm exploring various other flags to avoid the optimization in
> question.  We may need to get a similar flag added to gcc.
> 
> 3. Our linker doesn't tolerate R_SPARC_{8,16,32} relocations in
> objects being linked into 64-bit shared libraries.  These are
> converted to R_SPARC_RELATIVE relocations which require 8-byte
> alignment, even though the originals require smaller alignments.  This
> happens when gcc generates jump tables in the abs32 code model,
> something like:
> 
> .LL100:
> 	some code...
> .LL101:
> 	some code...
> 
> .LL500:
> 	.word	.LL100
> 	.word	.LL101
> 
> ...
> 
> 	sethi	%hi(.LL500), %g4
> 	or	%g4, %lo(.LL500), %g4
> 	lduw	[%g4+%g1], %g5
> 	jmp	%g5
> 	 nop
> 
> where %g1 is set to select the appropriate jump target from the table.
> 
> The linker behaviour is arguably correct; a shared library with this
> kind of code (in fact, almost any using the abs32 code model) will not
> work.  However, the shared libraries in question are libgenunix.so and
> similar used to resolve symbols when building other kernel modules.
> They are never run at all and in fact are not even delivered.  Mike
> Walker has made some suggestions and we're investigating the correct
> course of action.
> 
> 4. forthdebug (not included in OpenSolaris) uses the stabs tool, which
> in turn relies on a compiler generating stabs debug data in a
> particular format.  gcc doesn't provide this, so I've converted this
> to use ctfstabs instead.  ctfstabs understands DWARF debugging data,
> which gcc does provide, and also provides better checking of the forth
> template files.  As a result, I've uncovered a few other bugs in
> ctfstabs that we'll need to fix (specifically, it ignores parts of the
> template that tell it which structure members to output and the format
> to use when doing so).
> 
> With all this, I can get all the way to the login prompt, but missing
> symbols prevent the ip module from loading, which is pretty much a
> showstopper.  More to come.
> 


From mike_s at yavin.Eng.Sun.COM  Wed Apr  6 10:42:12 2005
From: mike_s at yavin.Eng.Sun.COM (Mike Sullivan)
Date: Wed, 6 Apr 2005 10:42:12 -0700 (PDT)
Subject: [gcc] Re: SPARC/gcc kernel status
Message-ID: <200504061742.j36HgCkp367046@yavin.Eng.Sun.COM>


I risked bfu'ing intel today:

Running Configuration Assistant...
Autobooting from bootpath: /pci at 0,0/pci-ide at 1f,1/ide at 0/cmdk at 0,0:a


If the system hardware has changed, or to boot from a different
device, interrupt the autoboot process by pressing ESC.

                                                    
Initializing system
Please wait...


                     <<< Current Boot Parameters >>>
Boot path: /pci at 0,0/pci-ide at 1f,1/ide at 0/cmdk at 0,0:a
Boot args: 

Type    b [file-name] [boot-flags] <ENTER>      to boot with options
or      i <ENTER>                               to enter boot interpreter
or      <ENTER>                                 to boot with defaults

                  <<< timeout in 5 seconds >>>

Select (b)oot or (i)nterpreter: pLoading kmdb...
SunOS Release 5.10.1 Version sinestro:gcc-fixes:04-05-2005 32-bit
Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
DEBUG enabled
Built with gcc
Configuring devices.
Hostname: stargazer
NIS domain name is it.sfbay.sun.com
checking ufs filesystems
/dev/rdsk/c1d0s5: is logging.
/dev/rdsk/c1d0s7: is logging.

stargazer console login: 

*****************************************************************************
*
* Starting Desktop Login on display :0...
*
* Wait for the Desktop Login screen before logging in.
*
*****************************************************************************
gk
Password: 
Apr  6 10:37:22 stargazer login: ROOT LOGIN /dev/console
Last login: Tue Apr  5 14:25:45 on console
Sun Microsystems Inc.   SunOS 5.10.1    sinestro:gcc-fixes:04-05-2005   Apr. 05, 
2005
SunOS Internal Development:  gk 2005-04-05 [gcc-fixes]
bfu'ed from /net/sinestro/builds/gcc-fixes/archives/i386/nightly on 2005-04-06
{root:stargazer:1} ps -e
    PID TTY         TIME CMD
     0 ?           0:43 sched
     1 ?           0:00 init
     2 ?           0:00 pageout
     3 ?           0:00 fsflush
100294 ?           0:00 keyserv
100004 ?           0:04 svc.star
100006 ?           0:08 svc.conf
100132 ?           0:00 picld
100436 ?           0:01 inetd
100138 ?           0:00 powerd
100937 ?           0:00 nscd
100545 ?           0:00 mountd
101368 ?           0:00 inetconv
100173 ?           0:00 in.route
100553 ?           0:00 nfsd
100323 ?           0:00 nfs4cbd
100332 ?           0:00 cron
100113 ?           0:00 sysevent
100139 ?           0:00 kcfd
100137 ?           0:00 nscd
100279 ?           0:00 rpcbind
100222 ?           0:00 in.ndpd
100668 ?           0:00 smcboot
100346 ?           0:00 ttymon
100290 ?           0:00 statd
100292 ?           0:00 ypbind
100293 ?           0:00 lockd
100329 console     0:00 csh
100319 ?           0:00 sac
100320 ?           0:00 nfsmapid
100330 ?           0:00 utmpd
100347 ?           0:00 xntpd
100587 ?           0:00 sshd
100562 ?           0:00 fmd
100670 ?           0:00 smcboot
101019 ?           0:00 inetd-up
100532 ?           0:00 automoun
100570 ?           0:00 syslogd
100818 ?           0:02 svc.star
100753 ?           0:00 vold
100612 ?           0:00 sendmail
100613 ?           0:00 sendmail
100663 ?           0:00 smcboot
100705 ?           0:00 dtlogin
101216 ?           0:00 <defunct>
100797 ?           0:00 zsched
101020 ?           0:00 inetd-up
100713 ?           0:01 Xorg
100722 ?           0:00 snmpdx
100745 ?           0:00 dmispd
100746 ?           0:00 snmpXdmi
100786 ?           0:00 zoneadmd
100820 ?           0:06 svc.conf
100796 ?           0:00 zsched
100772 ?           0:00 dtlogin
101392 console     0:00 ps
100785 ?           0:00 zoneadmd
100827 ?           0:02 svc.star
100783 ?           0:00 snmpd
100793 ?           0:00 rpc.smse
100825 ?           0:00 init
100829 ?           0:06 svc.conf
101101 ?           0:00 ttymon
100791 ?           0:00 devfsadm
100816 ?           0:00 init
101115 ?           0:00 cron
100872 ?           0:00 nscd
101038 ?           0:00 rpcbind
101046 ?           0:00 statd
101053 ?           0:00 ypbind
100869 ?           0:00 kcfd
101391 ?           0:00 svccfg
100932 ?           0:00 kcfd
101037 ?           0:00 rpcbind
101098 ?           0:00 nfs4cbd
101051 ?           0:00 statd
101064 ?           0:00 sac
101077 ?           0:00 keyserv
101061 ?           0:00 lockd
101106 ?           0:00 cron
101114 ?           0:00 utmpd
101067 ?           0:00 lockd
101362 ?           0:00 inetconv
101072 ?           0:00 ypbind
101075 ?           0:00 sac
101182 ?           0:00 dtgreet
101104 zoneconsole    0:00 ttymon
101390 ?           0:00 svccfg
101107 ?           0:00 ttymon
101097 ?           0:00 nfsmapid
101093 ?           0:00 utmpd
101094 ?           0:00 nfsmapid
101117 zoneconsole    0:00 ttymon
101096 ?           0:00 nfs4cbd
101100 ?           0:00 keyserv
{root:stargazer:2} zoneadm list
global
doomsday
whizzy
{root:stargazer:3} ping doomsday
doomsday is alive
{root:stargazer:4} ping whizzy
whizzy is alive
{root:stargazer:5} ping yavin
yavin is alive
{root:stargazer:6} uptime
 10:37am  up 2 min(s),  1 user,  load average: 1.18, 0.51, 0.20
{root:stargazer:7} uname -a
SunOS stargazer 5.10.1 sinestro:gcc-fixes:04-05-2005 i86pc i386 i86pc
{root:stargazer:8} ls /usr/local
./                    egcs/                 mysql-test/
../                   electric/             netscape/
BerkeleyDB/           enlightenment/        nmh/
BerkeleyDB.3.1/       etc/                  qt@
BerkeleyDB.4.2/       flexlm/               qt-x11-free-3.3.3/
GNUstep/              gprolog-1.2.13/       samba/
LessTif/              i386-pc-solaris2.10/  sbin/
X11R6/                include/              share/
Xbin/                 info/                 sql-bench/
Xman/                 kde/                  squid/
apr/                  lib/                  src/
bin/                  libexec/              ssl/
bind/                 linux@                teTeX/
com/                  lost+found/           var/
cygnus/               lxrun@                vnc/
doc/                  man/
{root:stargazer:9} df -k /usr/local
Filesystem            kbytes    used   avail capacity  Mounted on
yavin.SFBay:/export/local/i386
                     17413250 15558985 1680133    91%    /usr/local
{root:stargazer:10} 

Seems to work though I may go fix all the kernel warnings since the 2
warnings in segkmem.c actually were the cause of my panic.

The man command even works with my I-don't-know-C++-but-I'll-just-change-things-
until-it-compiles hacks.

	Mike
	
>Date: Tue, 5 Apr 2005 21:25:52 -0700
>From: Keith M Wesolowski <keith.wesolowski at sun.com>
>To: gcc at opensolaris.org, mike_s at eng.sun.com
>Subject: SPARC/gcc kernel status
>Mime-Version: 1.0
>Content-Disposition: inline
>User-Agent: Mutt/1.4.2.1i
>
>The gcc-built SPARC kernel can boot, with the following two
>exceptions:
>
>1. krtld is still busted as described previously.
>
>2. The md5 module doesn't work because we need to implement the
>load_little_32 inline.  This module is depended upon by almost
>everything, and ultimately the failure prevents ip from loading.
>
>Replacing just these two modules with their standard versions, I can
>boot, log in, and use the network.  There are a large number of
>warnings from fbt at startup of the form:
>
>NOTICE: strange leaf jmpl/call delay at 7b277b48
>
>and
>
>NOTICE: cannot instrument relock_skip_pid: begins with non-ba CTI
>
>I'll start tracking these down tomorrow.  I should note that dtrace is
>at least partially functional even with these warnings.  Presumably
>the problem is either more odd jump table entries or an unusual gcc
>instruction pattern.
>
>-- 
>Keith M Wesolowski		"Sir, we're surrounded!" 
>Solaris Kernel Team		"Excellent; we can attack in any direction!" 



From kupfer at athyra.eng.sun.com  Wed Apr  6 11:16:06 2005
From: kupfer at athyra.eng.sun.com (Mike Kupfer)
Date: Wed, 06 Apr 2005 11:16:06 -0700
Subject: [gcc] Re: SPARC/gcc kernel status 
In-Reply-To: Message from Mike Sullivan <mike_s@yavin.eng.sun.com> of "Wed,
	06 Apr 2005 10:42:12 PDT."
	<200504061742.j36HgCkp367046@yavin.Eng.Sun.COM> 
Message-ID: <200504061816.j36IG6uh259676@athyra.eng.sun.com>

> I risked bfu'ing intel today:

Cool!

mike


From keith.wesolowski at sun.com  Wed Apr  6 11:28:07 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Wed, 6 Apr 2005 11:28:07 -0700
Subject: [gcc] First SPARC performance data
Message-ID: <20050406182806.GB737@sun.com>

Last night I managed to do a full libmicro run against gcc and devpro
kernels on a 2-CPU SunFire V210.  The results[0] are at
http://jurassic.eng/~wesolows/gccvdevpro.html and are attached for
those without SWAN access.  The full data are in
http://jurassic.eng/~wesolows/{gcc,devpro}.{lm,lma}, where lm is the
full output and lma is the output of benchavg.

Caveats: Not all inlines are implemented for gcc yet.  krtld and md5
(neither of which should have any impact) were built with devpro for
both tests.  Userland and libmicro binaries were identical for both
tests, so tests affected primarily by libc are not relevant.

The highlights: There are 257 tests.  Based on averages, here's the
overall breakdown:

Difference < 1%:	42
gcc ahead < 10%:	30
devpro ahead < 10%:	104
gcc ahead 10%+:		9
devpro ahead 10%+:	72

No errors were reported during the gcc tests.

gcc's best result was a 37% advantage (gcc/devpro = 0.63) on the
mallocT2_100k test.  devpro's best result was a 33% advantage
(devpro/gcc = 0.67) on all three pwrite_n tests.

[0] which, like all libmicro benchmarks, are confidential

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.opensolaris.org/pipermail/gcc/attachments/20050406/79cdbac0/attachment.html>

From kritter at eng.sun.com  Wed Apr  6 13:49:31 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Wed, 06 Apr 2005 13:49:31 -0700
Subject: [gcc] Re: SPARC/gcc kernel status
In-Reply-To: <200504061742.j36HgCkp367046@yavin.Eng.Sun.COM>
References: <200504061742.j36HgCkp367046@yavin.Eng.Sun.COM>
Message-ID: <42544B5B.2040303@eng.sun.com>

That's great news!

Mike Sullivan wrote:
> I risked bfu'ing intel today:
> 
> Running Configuration Assistant...
> Autobooting from bootpath: /pci at 0,0/pci-ide at 1f,1/ide at 0/cmdk at 0,0:a
> 
> 
> If the system hardware has changed, or to boot from a different
> device, interrupt the autoboot process by pressing ESC.
> 
>                                                     
> Initializing system
> Please wait...
> 
> 
>                      <<< Current Boot Parameters >>>
> Boot path: /pci at 0,0/pci-ide at 1f,1/ide at 0/cmdk at 0,0:a
> Boot args: 
> 
> Type    b [file-name] [boot-flags] <ENTER>      to boot with options
> or      i <ENTER>                               to enter boot interpreter
> or      <ENTER>                                 to boot with defaults
> 
>                   <<< timeout in 5 seconds >>>
> 
> Select (b)oot or (i)nterpreter: pLoading kmdb...
> SunOS Release 5.10.1 Version sinestro:gcc-fixes:04-05-2005 32-bit
> Copyright 1983-2005 Sun Microsystems, Inc.  All rights reserved.
> Use is subject to license terms.
> DEBUG enabled
> Built with gcc
> Configuring devices.
> Hostname: stargazer
> NIS domain name is it.sfbay.sun.com
> checking ufs filesystems
> /dev/rdsk/c1d0s5: is logging.
> /dev/rdsk/c1d0s7: is logging.
> 
> stargazer console login: 
> 
> *****************************************************************************
> *
> * Starting Desktop Login on display :0...
> *
> * Wait for the Desktop Login screen before logging in.
> *
> *****************************************************************************
> gk
> Password: 
> Apr  6 10:37:22 stargazer login: ROOT LOGIN /dev/console
> Last login: Tue Apr  5 14:25:45 on console
> Sun Microsystems Inc.   SunOS 5.10.1    sinestro:gcc-fixes:04-05-2005   Apr. 05, 
> 2005
> SunOS Internal Development:  gk 2005-04-05 [gcc-fixes]
> bfu'ed from /net/sinestro/builds/gcc-fixes/archives/i386/nightly on 2005-04-06
> {root:stargazer:1} ps -e
>     PID TTY         TIME CMD
>      0 ?           0:43 sched
>      1 ?           0:00 init
>      2 ?           0:00 pageout
>      3 ?           0:00 fsflush
> 100294 ?           0:00 keyserv
> 100004 ?           0:04 svc.star
> 100006 ?           0:08 svc.conf
> 100132 ?           0:00 picld
> 100436 ?           0:01 inetd
> 100138 ?           0:00 powerd
> 100937 ?           0:00 nscd
> 100545 ?           0:00 mountd
> 101368 ?           0:00 inetconv
> 100173 ?           0:00 in.route
> 100553 ?           0:00 nfsd
> 100323 ?           0:00 nfs4cbd
> 100332 ?           0:00 cron
> 100113 ?           0:00 sysevent
> 100139 ?           0:00 kcfd
> 100137 ?           0:00 nscd
> 100279 ?           0:00 rpcbind
> 100222 ?           0:00 in.ndpd
> 100668 ?           0:00 smcboot
> 100346 ?           0:00 ttymon
> 100290 ?           0:00 statd
> 100292 ?           0:00 ypbind
> 100293 ?           0:00 lockd
> 100329 console     0:00 csh
> 100319 ?           0:00 sac
> 100320 ?           0:00 nfsmapid
> 100330 ?           0:00 utmpd
> 100347 ?           0:00 xntpd
> 100587 ?           0:00 sshd
> 100562 ?           0:00 fmd
> 100670 ?           0:00 smcboot
> 101019 ?           0:00 inetd-up
> 100532 ?           0:00 automoun
> 100570 ?           0:00 syslogd
> 100818 ?           0:02 svc.star
> 100753 ?           0:00 vold
> 100612 ?           0:00 sendmail
> 100613 ?           0:00 sendmail
> 100663 ?           0:00 smcboot
> 100705 ?           0:00 dtlogin
> 101216 ?           0:00 <defunct>
> 100797 ?           0:00 zsched
> 101020 ?           0:00 inetd-up
> 100713 ?           0:01 Xorg
> 100722 ?           0:00 snmpdx
> 100745 ?           0:00 dmispd
> 100746 ?           0:00 snmpXdmi
> 100786 ?           0:00 zoneadmd
> 100820 ?           0:06 svc.conf
> 100796 ?           0:00 zsched
> 100772 ?           0:00 dtlogin
> 101392 console     0:00 ps
> 100785 ?           0:00 zoneadmd
> 100827 ?           0:02 svc.star
> 100783 ?           0:00 snmpd
> 100793 ?           0:00 rpc.smse
> 100825 ?           0:00 init
> 100829 ?           0:06 svc.conf
> 101101 ?           0:00 ttymon
> 100791 ?           0:00 devfsadm
> 100816 ?           0:00 init
> 101115 ?           0:00 cron
> 100872 ?           0:00 nscd
> 101038 ?           0:00 rpcbind
> 101046 ?           0:00 statd
> 101053 ?           0:00 ypbind
> 100869 ?           0:00 kcfd
> 101391 ?           0:00 svccfg
> 100932 ?           0:00 kcfd
> 101037 ?           0:00 rpcbind
> 101098 ?           0:00 nfs4cbd
> 101051 ?           0:00 statd
> 101064 ?           0:00 sac
> 101077 ?           0:00 keyserv
> 101061 ?           0:00 lockd
> 101106 ?           0:00 cron
> 101114 ?           0:00 utmpd
> 101067 ?           0:00 lockd
> 101362 ?           0:00 inetconv
> 101072 ?           0:00 ypbind
> 101075 ?           0:00 sac
> 101182 ?           0:00 dtgreet
> 101104 zoneconsole    0:00 ttymon
> 101390 ?           0:00 svccfg
> 101107 ?           0:00 ttymon
> 101097 ?           0:00 nfsmapid
> 101093 ?           0:00 utmpd
> 101094 ?           0:00 nfsmapid
> 101117 zoneconsole    0:00 ttymon
> 101096 ?           0:00 nfs4cbd
> 101100 ?           0:00 keyserv
> {root:stargazer:2} zoneadm list
> global
> doomsday
> whizzy
> {root:stargazer:3} ping doomsday
> doomsday is alive
> {root:stargazer:4} ping whizzy
> whizzy is alive
> {root:stargazer:5} ping yavin
> yavin is alive
> {root:stargazer:6} uptime
>  10:37am  up 2 min(s),  1 user,  load average: 1.18, 0.51, 0.20
> {root:stargazer:7} uname -a
> SunOS stargazer 5.10.1 sinestro:gcc-fixes:04-05-2005 i86pc i386 i86pc
> {root:stargazer:8} ls /usr/local
> ./                    egcs/                 mysql-test/
> ../                   electric/             netscape/
> BerkeleyDB/           enlightenment/        nmh/
> BerkeleyDB.3.1/       etc/                  qt@
> BerkeleyDB.4.2/       flexlm/               qt-x11-free-3.3.3/
> GNUstep/              gprolog-1.2.13/       samba/
> LessTif/              i386-pc-solaris2.10/  sbin/
> X11R6/                include/              share/
> Xbin/                 info/                 sql-bench/
> Xman/                 kde/                  squid/
> apr/                  lib/                  src/
> bin/                  libexec/              ssl/
> bind/                 linux@                teTeX/
> com/                  lost+found/           var/
> cygnus/               lxrun@                vnc/
> doc/                  man/
> {root:stargazer:9} df -k /usr/local
> Filesystem            kbytes    used   avail capacity  Mounted on
> yavin.SFBay:/export/local/i386
>                      17413250 15558985 1680133    91%    /usr/local
> {root:stargazer:10} 
> 
> Seems to work though I may go fix all the kernel warnings since the 2
> warnings in segkmem.c actually were the cause of my panic.
> 
> The man command even works with my I-don't-know-C++-but-I'll-just-change-things-
> until-it-compiles hacks.
> 
> 	Mike
> 	
> 
>>Date: Tue, 5 Apr 2005 21:25:52 -0700
>>From: Keith M Wesolowski <keith.wesolowski at sun.com>
>>To: gcc at opensolaris.org, mike_s at eng.sun.com
>>Subject: SPARC/gcc kernel status
>>Mime-Version: 1.0
>>Content-Disposition: inline
>>User-Agent: Mutt/1.4.2.1i
>>
>>The gcc-built SPARC kernel can boot, with the following two
>>exceptions:
>>
>>1. krtld is still busted as described previously.
>>
>>2. The md5 module doesn't work because we need to implement the
>>load_little_32 inline.  This module is depended upon by almost
>>everything, and ultimately the failure prevents ip from loading.
>>
>>Replacing just these two modules with their standard versions, I can
>>boot, log in, and use the network.  There are a large number of
>>warnings from fbt at startup of the form:
>>
>>NOTICE: strange leaf jmpl/call delay at 7b277b48
>>
>>and
>>
>>NOTICE: cannot instrument relock_skip_pid: begins with non-ba CTI
>>
>>I'll start tracking these down tomorrow.  I should note that dtrace is
>>at least partially functional even with these warnings.  Presumably
>>the problem is either more odd jump table entries or an unusual gcc
>>instruction pattern.
>>
>>-- 
>>Keith M Wesolowski		"Sir, we're surrounded!" 
>>Solaris Kernel Team		"Excellent; we can attack in any direction!" 
> 
> 
> _______________________________________________
> gcc mailing list
> gcc at opensolaris.org
> https://www.opensolaris.org/mailman/listinfo/gcc


From keith.wesolowski at sun.com  Wed Apr  6 13:54:32 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Wed, 6 Apr 2005 13:54:32 -0700
Subject: [gcc] SPARC tools, gcc-gate information
Message-ID: <20050406205431.GA1923@sun.com>

gcc-gate will not be sync'd with onnv for the next few days, to allow
sun4v to stabilize.  I plan to resume daily syncing on Monday 4/11.

Several people have mentioned that access to tools to use with gcc is
more difficult than it should be.  I apologize for the delay in fixing
this, and for time lost working around the tools shortcomings.  I've
now made available the following:

- The modified gcc (now including the DWARF direct string hack) for
SPARC is in /net/tonic-gate/tonic/gcc-tools/sparc/gcc-3.4.3.  Set
GNU_ROOT to this directory and you will be using the latest compiler.
I'll be updating it again in the next few days to take advantage of
CSL's latest fixes.  x86 users do not need a special compiler.

- Current tools for both x86 and SPARC are in
/net/tonic-gate/tonic/gcc-tools/onbld.  Set ONBLD_TOOLS to this
directory if you don't want to bother rebuilding the tools.  The cw
included here has warnings-to-errors disabled so that you can build
without fixing the warnings.

- Putbacks to gcc-gate are now logged in public/putbacks/current.

For those without SWAN access:

- The compiler and tools will be available shortly for local
installation from
https://www.opensolaris.org/downloads/tools/index.jsp.  You need the
onbld (for both platforms) and compiler (SPARC only).  You can unpack
these in any location, setting GNU_ROOT and ONBLD_TOOLS to point to
the install locations as described above.

Building your own gcc:

If you want to build gcc yourself, I'm also posting the sources, as
required by the terms of the GPL, and the script and configuration
I've used to build it.  You will need gcc and gmake already installed.
Use it like:

bzip2 -dc gcc-3.4.3-csl.tar.bz2 | tar xf -
vi gcc.on
[set PREFIX as desired]
mkdir gcc-build
cd gcc-build
PATH=$PATH:/usr/sfw/bin; export PATH
../build-gcc ../gcc.on

By default, when this completes you will have gcc installed in the
location specified in gcc.on.

Changing GAS, GLD, AS, or LD will cause your gcc-enabled ON build to
fail.  These values should not be modified.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From keith.wesolowski at sun.com  Thu Apr  7 12:55:49 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 7 Apr 2005 12:55:49 -0700
Subject: [gcc] fbt and gcc
Message-ID: <20050407195549.GB737@sun.com>

Two minor problems are noted with fbt when using kernels compiled with
gcc:

1. Tables containing legal but meaningless instructions trigger
warnings of the form:

Apr  6 18:07:27 flask fbt: [ID 783403 kern.notice] NOTICE: strange leaf jmpl/call delay at 7b277b60
Apr  6 18:07:27 flask fbt: [ID 783403 kern.notice] NOTICE: strange leaf jmpl/call delay at 7b277b64
Apr  6 18:07:27 flask fbt: [ID 783403 kern.notice] NOTICE: strange leaf jmpl/call delay at 7b277b68
Apr  6 18:07:27 flask fbt: [ID 783403 kern.notice] NOTICE: strange leaf jmpl/call delay at 7b277b6c

The instructions in question look like:

geterrno+0x140:                 call      -0x136216d0   <0x67c56490>
geterrno+0x144:                 call      -0x136216d0   <0x67c56494>
geterrno+0x148:                 call      -0x136216b0   <0x67c564b8>
0x7b277b6c:                     illtrap   0
0x7b277b70:                     illtrap   0

Since these aren't really calls, fbt does the right thing.  The
messages are harmless but voluminous.

The examples I've looked at invariably have the table between
functions.  Determining that these instructions are unreachable,
however, seems impractical.  Any suggestions?

2. fbt refuses to instrument functions whose first instruction is a
branch other than non-annulled ba.  However, gcc compiles functions
like

int
foo(void *bar) {
	if (bar == NULL)
	    return (0);

	...
}

into

failover_safe:                  brz,pn    %o0, +0x38    <failover_safe+0x38>
failover_safe+4:                clr       %o5
failover_safe+8:                ldx       [%o0], %o0
...

which is not incorrect.  There are unfortunately quite a few of these
functions, though the only negative impact is that they aren't
instrumented and warnings are issued on the console.  A grovel through
bugster doesn't show that anyone's run across this yet.  How difficult
would it be to instrument these?

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From bmc at zion.eng.sun.com  Thu Apr  7 13:07:22 2005
From: bmc at zion.eng.sun.com (Bryan Cantrill)
Date: Thu, 7 Apr 2005 13:07:22 -0700 (PDT)
Subject: [gcc] Re: [DTrace] fbt and gcc
In-Reply-To: <20050407195549.GB737@sun.com> from Keith M Wesolowski at "Apr 7,
	2005 12:55:49 pm"
Message-ID: <200504072007.j37K7MCH019411@zion.eng.sun.com>


> The instructions in question look like:
> 
> geterrno+0x140:                 call      -0x136216d0   <0x67c56490>
> geterrno+0x144:                 call      -0x136216d0   <0x67c56494>
> geterrno+0x148:                 call      -0x136216b0   <0x67c564b8>
> 0x7b277b6c:                     illtrap   0
> 0x7b277b70:                     illtrap   0
> 
> Since these aren't really calls, fbt does the right thing.  The
> messages are harmless but voluminous.
> 
> The examples I've looked at invariably have the table between
> functions.  Determining that these instructions are unreachable,
> however, seems impractical.  Any suggestions?

Hmmm....the fact that they are inside the bounds of the text symbol makes
this difficult.  I think the message should probably just be suppressed
if this is coming up often...

> 2. fbt refuses to instrument functions whose first instruction is a
> branch other than non-annulled ba.  However, gcc compiles functions
> like
> 
> int
> foo(void *bar) {
> 	if (bar == NULL)
> 	    return (0);
> 
> 	...
> }
> 
> into
> 
> failover_safe:                  brz,pn    %o0, +0x38    <failover_safe+0x38>
> failover_safe+4:                clr       %o5
> failover_safe+8:                ldx       [%o0], %o0
> ...
> 
> which is not incorrect.  There are unfortunately quite a few of these
> functions, though the only negative impact is that they aren't
> instrumented and warnings are issued on the console.  A grovel through
> bugster doesn't show that anyone's run across this yet.  How difficult
> would it be to instrument these?

If they're all branch on register conditions, it's not terribly difficult --
just a tad unpleasant.  If they're branching on condition codes, that's
much more of a pain -- but it seems very unlikely that such senseless
code would be generated.  (I would say that such code would always be 
incorrect, but I suppose it could still be technically correct to have
something like "bg,a +8 ; nop" as a function preamble.)

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc


From kritter at eng.sun.com  Wed Apr 13 15:59:41 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Wed, 13 Apr 2005 15:59:41 -0700
Subject: [gcc] checking in...
Message-ID: <425DA45D.3020205@eng.sun.com>

I just wanted to check in with everyone and find out where you are on 
the gcc work:

   * Andrei: Have you handed off your libc changes to Craig? Have you
     talked to Keith about what other work needs to be done? Will you be
     done by Friday (4/15)?

   * Craig: Do you have everything you need from Andrei and Keith? When
     will you be done with your work? I originally had you down for 4/5,
     but that was before you needed changes from Andrei. Can you be done
     by Friday (4/15)?

   * Matt: Have you talked to Keith about what else needs to be done?
     When do you think you will be done? (And can you be done by Friday
     4/15?)

Any updates the rest of you want to give would probably be appreciated. 
Keith has filed a few bugs and RFEs. Mike Walker is working on the 
linker RFE, and I'm following up with the responsible managers and 
engineers to the others are being worked on.

We're hoping to hear back from CSL on a couple of the issues we've 
logged with them recently.

Thanks,

Karyn


From Craig.Mohrman at eng.sun.com  Wed Apr 13 16:06:31 2005
From: Craig.Mohrman at eng.sun.com (Craig Mohrman)
Date: Wed, 13 Apr 2005 16:06:31 -0700 (PDT)
Subject: [gcc] checking in...
Message-ID: <200504132306.j3DN6Wq4391269@jurassic.eng.sun.com>


>   * Craig: Do you have everything you need from Andrei and Keith? When
>     will you be done with your work? I originally had you down for 4/5,
>     but that was before you needed changes from Andrei. Can you be done
>     by Friday (4/15)?

No.  Andrei is getting close I believe.

I have one putback to do into nevada.
Otherwise I have only some testing to run.

I'll be done by friday.

craig



From dorofeev at gmail.com  Wed Apr 13 17:25:28 2005
From: dorofeev at gmail.com (Andrei Dorofeev)
Date: Wed, 13 Apr 2005 17:25:28 -0700
Subject: [gcc] checking in...
In-Reply-To: <425DA45D.3020205@eng.sun.com>
References: <425DA45D.3020205@eng.sun.com>
Message-ID: <a782ada905041317254c3e10a9@mail.gmail.com>

>    * Andrei: Have you handed off your libc changes to Craig? Have you
>      talked to Keith about what other work needs to be done? Will you be
>      done by Friday (4/15)?

I will.   I am going to give my libc changes to Craig later today or tomorrow
morning.  I've got a 32-bit sparc version of libc working (well, I can run "ls"
and similar programs with it, but haven't tried anything more substantial).

- Andrei


From Craig.Mohrman at eng.sun.com  Mon Apr 18 16:49:15 2005
From: Craig.Mohrman at eng.sun.com (Craig Mohrman)
Date: Mon, 18 Apr 2005 16:49:15 -0700 (PDT)
Subject: [gcc] gcc libc running on otherwise solaris x86
Message-ID: <200504182349.j3INnTIV358343@jurassic.eng.sun.com>

As an experiment I took my gcc compiled libc and replaced my libc's
on my Sun compiled Solaris x86 and I'm running just fine.
It just works.

craig



From kritter at eng.sun.com  Mon Apr 18 18:52:07 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Mon, 18 Apr 2005 18:52:07 -0700
Subject: [gcc] Re: gcc libc running on otherwise solaris x86
In-Reply-To: <200504182349.j3INnTIV358343@jurassic.eng.sun.com>
References: <200504182349.j3INnTIV358343@jurassic.eng.sun.com>
Message-ID: <42646447.8020405@eng.sun.com>

Craig,

That's great news! So, when's the putback? :)

I actually meant to send email to you, Matt, and Andrei today asking if 
you'll be able to putback by Thursday. I know it may be a stretch, but 
it would be great: I'm offline (on vacation) starting Friday (4/20) and 
all next week. Also, this would mean that Keith and Mike can move on to 
the next stage of the gcc work.

I'd love to get this stuff settled before I go.

Matt?

Andrei?

Thanks!

Karyn

Craig Mohrman wrote:
> As an experiment I took my gcc compiled libc and replaced my libc's
> on my Sun compiled Solaris x86 and I'm running just fine.
> It just works.
> 
> craig
> 


From craigm at jurassic.sfbay.sun.com  Tue Apr 19 10:31:33 2005
From: craigm at jurassic.sfbay.sun.com (Craig Mohrman)
Date: Tue, 19 Apr 2005 10:31:33 -0700 (PDT)
Subject: [gcc] Re: gcc libc running on otherwise solaris x86
Message-ID: <200504191731.j3JHVmWu652336@jurassic.eng.sun.com>

My one trivial putback occurred directly into onnv last thursday.
6253602 assfail.c needs a little coercion cleanup for gcc to work
This allows libc to compile warning free.
I'm been lightly testing this libc for sometime.

So I believe x86 libc is ok.
It's sparc libc that needs Andrei's assembly work and he has much
of that done and we can now build a sparc libc.  But Andrei's got more
to do.

But my experiment below is not directly useful.  It's just a proof
of concept that these parts are really interchangable as we would expect.

I heard that Mike has a full x86 build going so I might try to install that
and run some tests.

craig

>Date: Mon, 18 Apr 2005 18:52:07 -0700
>From: Karyn Ritter <kritter at eng.sun.com>
>Subject: Re: gcc libc running on otherwise solaris x86
>To: Craig Mohrman <Craig.Mohrman at eng.sun.com>
>Cc: gcc at opensolaris.org
>
>Craig,
>
>That's great news! So, when's the putback? :)
>
>I actually meant to send email to you, Matt, and Andrei today asking if 
>you'll be able to putback by Thursday. I know it may be a stretch, but 
>it would be great: I'm offline (on vacation) starting Friday (4/20) and 
>all next week. Also, this would mean that Keith and Mike can move on to 
>the next stage of the gcc work.
>
>I'd love to get this stuff settled before I go.
>
>Matt?
>
>Andrei?
>
>Thanks!
>
>Karyn
>
>Craig Mohrman wrote:
>> As an experiment I took my gcc compiled libc and replaced my libc's
>> on my Sun compiled Solaris x86 and I'm running just fine.
>> It just works.
>> 
>> craig
>> 



From keith.wesolowski at sun.com  Thu Apr 28 18:16:45 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 28 Apr 2005 18:16:45 -0700
Subject: [gcc] gcc-gate linker flag day
Message-ID: <20050429011644.GB106598@sun.com>

With my putback to gcc-gate for:

Eliminate duplicate SUBDIRS definition
Avoid DWARF2 indirect strings when generating CTF
Add the -znoreloc flag for ld
Build kernel shared libraries with -znoreloc

you will need to use a linker which includes the fix for

6254364 ld won't build libgenunix.so with absolute relocations

to build the kernel.  This fix is in builds starting with 19 April.

Alternately, if you are building on x86 or with DevPro, you can use an
older linker by changing the line in usr/src/Makefile.master from:

ZNORELOC=       -znoreloc

to

ZNORELOC=

The linker fix is required for building with gcc on SPARC; there is no
workaround.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From keith.wesolowski at sun.com  Thu Apr 28 18:46:51 2005
From: keith.wesolowski at sun.com (Keith M Wesolowski)
Date: Thu, 28 Apr 2005 18:46:51 -0700
Subject: [gcc] gcc compiler update and x86 flag day
In-Reply-To: <20050429011644.GB106598@sun.com>
References: <20050429011644.GB106598@sun.com>
Message-ID: <20050429014651.GC106598@sun.com>

If you don't build gcc-gate sources on x86 and don't care about
updates to the gcc-gate compilers, you don't need to read any farther.

With my putback to gcc-gate for:

Avoid DWARF2 indirect strings when generating CTF

you will need to use a compiler which supports the
-fno-dwarf2-indirect-strings flag on both x86 and SPARC.  Users of the
existing SPARC compiler on tonic-gate will not notice any change.

However, x86 users must now use the modified compiler.  To do this,
set the GNU_ROOT environment variable to
/net/tonic-gate/tonic/gcc-tools/i386/gcc-3.4.3.

Both the x86 and SPARC compilers also incorporate fixes for the
following CodeSourcery issues:

250 possible pragma weak problem
228 Stop emitting duplicate .weak directives
229 Allow disabling of warnings for pointer-to-integer conversions

and now accept the following new flags:

-W[no-]pointer-to-int-cast

Do [not] warn when casting from a pointer to an integer of a different
size.  This warning should not be disabled; you should use proper
casts instead.

-W[no-]int-to-pointer-cast

Do [not] warn when casting from an integer to a pointer of a different
size.  This warning should not be disabled; you should use proper
casts instead.

-f[no-]dwarf2-indirect-strings

Do [not] use indirect strings (DW_FORM_strp) when generating DWARF2
debugging information.  This is a workaround for ctfconvert on SPARC.

The updated compilers and diffs will appear on opensolaris.org in the
Tools Community tomorrow.

-- 
Keith M Wesolowski		"Sir, we're surrounded!" 
Solaris Kernel Team		"Excellent; we can attack in any direction!" 


From kritter at eng.sun.com  Fri Apr 29 12:20:33 2005
From: kritter at eng.sun.com (Karyn Ritter)
Date: Fri, 29 Apr 2005 12:20:33 -0700
Subject: [gcc] what's happening?
Message-ID: <42728901.1030607@eng.sun.com>

I'm back from Hawaii, though technically not back from vacation...


I just searched through my email and didn't see an update from Craig, 
Matt, or Andrei. Can you all send an email update about when you think 
you'll be done? Apologies if you all have been talking about this off list.

Thanks,

Karyn


From dorofeev at gmail.com  Fri Apr 29 12:35:58 2005
From: dorofeev at gmail.com (Andrei Dorofeev)
Date: Fri, 29 Apr 2005 12:35:58 -0700
Subject: [gcc] what's happening?
In-Reply-To: <42728901.1030607@eng.sun.com>
References: <42728901.1030607@eng.sun.com>
Message-ID: <a782ada9050429123526cf0d48@mail.gmail.com>

I've managed to get a cold a couple of days ago so I'm working from
home trying to finish this project.  I've tried booting with libc compiled
with gcc and it didn't boot.  I think I know where the problem is and
working on fixing it today.
- Andrei

On 4/29/05, Karyn Ritter <kritter at eng.sun.com> wrote:
> I'm back from Hawaii, though technically not back from vacation...
> 
> I just searched through my email and didn't see an update from Craig,
> Matt, or Andrei. Can you all send an email update about when you think
> you'll be done? Apologies if you all have been talking about this off list.
> 
> Thanks,
> 
> Karyn
> _______________________________________________
> gcc mailing list
> gcc at opensolaris.org
> https://www.opensolaris.org/mailman/listinfo/gcc
>