I found a comment in <discuss> on March 6 that rings a big bell. Under the
thread "Building the kernel with Studio 11 supported?" Keith Wesolowski says in
part:
________
In some cases, using a different compiler may expose legitimate bugs
in ON code. We found many instances like this when porting to gcc.
If you think you've found such a bug, please file it! It's much
better to fix it now than to find it later after distributors have
shipped broken bits to their customers.
________
Over the years, I have found this to be spectacularly true--all the way back to
the early 70's when I was first involved in porting large, stable apps into a
virtual storage environment for the first time. Code that had run fine for
years before that, blew its top in a paging environment--because before, the
code had been occasionally re-using memory after it had been free()'d, and
nobody noticed--until free() *really* disappeared the memory!
OTOH, a large stress, such as building onnv, could expose new bugs in the new
Studio 11 compiler/assembler suite as well, of course.
On this failing snnv build using Studio 11 here, there are 1973 errors in
nightly.log. nightly.log is 54 megabytes, with very long lines as well, so it
was a bit of a chore to clunk around with it. Here are the first two
significant errors:
+ /opt/SUNWspro/bin/cc -xarch=amd64 -Ui386 -U__i386 -xO3
../../intel/amd64/ml/amd64.il -D_ASM_INLINES -Xa -xspace -Wu,-xmodel=kernel
-Wu,-save_args -v -xildoff -g -xc99=%none -W0,-noglobal -errtags=yes
-errwarn=%all -xc99=%all -D_KERNEL -D_SYSCALL32 -D_SYSCALL32_IMPL -D_ELF64
-D_DDI_STRICT -Dsun -D__sun -D__SVR4 -DDEBUG -D_SIMULATOR_SUPPORT -DC2_AUDIT
-DOPTERON_ERRATUM_88 -DOPTERON_ERRATUM_91 -DOPTERON_ERRATUM_93
-DOPTERON_ERRATUM_95 -DOPTERON_ERRATUM_100 -DOPTERON_ERRATUM_101
-DOPTERON_ERRATUM_108 -DOPTERON_ERRATUM_109 -DOPTERON_ERRATUM_121
-DOPTERON_ERRATUM_122 -DOPTERON_ERRATUM_131 -DOPTERON_WORKAROUND_6336786
-DOPTERON_WORKAROUND_6323525 -I../../intel -Y I,../../common
-I/export/tonic/WS20060619/usr/src/common -c -o debug64/hat.o
../../common/vm/hat.c
/export/tonic/WS20060619/usr/src/tools/proto/opt/onbld/bin/i386/ctfconvert -i
-L VERSION debug64/hat.o
ERROR: ctfconvert: file does not contain dwarf type data (try compiling with -g)
Removing debug64/hat.o
[and in the kernel link...]
/usr/ccs/bin/ld -dy -b -o debug32/unix -e _start -I misc/krtld -M
../../i86pc/conf/Mapfile \
./debug32/unix.o ./debug32/modstubs.o -L ../../intel/genunix/debug32 -l
genunix debug32/libdtracestubs.so
/export/tonic/WS20060619/usr/src/tools/proto/opt/onbld/bin/i386/ctfmerge -L
VERSION -d ../../intel/genunix/debug32/genunix -o debug32/unix debug32/locore.o
debug32/fast_trap_asm.o debug32/interrupt.o
debug32/syscall_asm.o debug32/muldiv.o
[...]
[...the .o litany for many files not shown...]
[...]
debug32/pit.o debug32/pic.o debug32/hardclk.o
debug32/i8254.o debug32/vers.o
ERROR: ctfmerge: No room for additional types in master
Removing debug32/unix
*** Error code 1
There are 619 occurrances of "ctfmerge: No room for additional types in master"
and 30 occurrances of the ctfconvert message shown above.
Due to time constraints, I haven't really looked hard at this, as you can tell,
but off the bat it feels to me a but like a resource constraint--a table
overflow or the like.
I may have more time to look at this over the weekend. For now, I'll try
Studio 10, and if that builds ON cleanly I'll look seriously at what Studio 11
might be up to.
--JCC
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
