Re: Solaris bootstrap failure

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Mike Stump <mrs@windriver.com>
 > 
 > > Date: Tue, 6 Mar 2001 23:27:23 -0500 (EST)
 > > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
 > 
 > > Any other ideas?
 > 
 > The standard technique of binary searching with cvs and full
 > bootstraps will tell you exactly what triggered it.  Though, as we
 > might guess now, that probably isn't the real bug.
 > 
 > If you modify the compiler used to be one that squirrels away the
 > complete environment, and the entire command line, and does -E on the
 > input file, and squirrels that away too, and a staging process that
 > stages those intermediate files as well, you might just be able to
 > observe it in action.

I tried something similar via adding --save-temps to BOOT_CFLAGS, but
then the failure went away.  I think using the integrated preprocessor
(which --save-temps turns off?) might be necessary.


 > Last time I saw one of these, someone had introduced a bit of non
 > initialized stack.  :-(

In that case, would testing with BPs or some kind of memory/malloc
checker help?  If someone can help try those, that would be great.


 > Another way that might allow one to observe this type of problem is to
 > build on tons of different hosts, and compare the output between the
 > hosts for the same target, on the same code.  Doing this for a full
 > range of inputs is best, as often, it will only be a smaller
 > percentage of files that trip it up.

Well we know cp/tree.o triggers it.  Perhaps if someone builds a
Bounded Pointer x86 cross to solaris2.7 I can supply the .i file from
a snapshot known to fail and we'll see if that helps trigger
something.

 > Bear in mind, binutils can also cause these types of problems, even
 > with identical .s files.  I've seen that too.  To narrow is done, one
 > can try a different binutils with a known to fail botstrap.

I'm using native tools.  They could contains bugs, I don't know.

as: WorkShop Compilers 5.0 Alpha 03/27/98 Build
ld: Software Generation Utilities - Solaris/ELF (3.0)
    and for stage1:
cc: WorkShop Compilers 5.0 98/12/15 C 5.0



 > And my last thought, with some luck, the binary searching for the
 > first instance of bootstrap failure, might lead to the actual code
 > that is broken.

The problem is, we can't *binary* search, cause the problem seems to
come and go on a day-by-day basis.  And since it only appeared when we
turned off --enable-checking on the branch we don't know how long its
been lurking in the sources hidden by the checking switch.

		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions