Stability and debugging

Robert Connolly robert at linuxfromscratch.org
Thu Jul 20 20:47:11 PDT 2006


Hi. I have been thinking that, at least with -unstable, we should do as much 
as possible to improve our ability to debug and stabilize the base packages.

There are two ways I can think of dealing with GCC optimizations. Either use 
every GCC optimization on every package and then debug them, or use no 
optimizations. Using every optimization will surface the most possible bugs, 
and create the most possible work to do. Using no optimizations does not fix 
anything, but makes it less likely that invalid/incorrect code will cause a 
problem. We are already using -pie, fortify_source, and -fstack options which 
still have unknown results with many packages. It's more realistic, for now, 
that we use the fewest optimizations possible to prevent unknown bugs from 
surfacing, even though this is like sticking your head in the sand. For the 
most part this is what LFS already does, but a few packages are exceptions. 
GCC uses -fomit-frame-pointer during bootstraps, and at least one package 
uses -funroll-loops. GCC also uses -mtune=pentiumpro by default on i686's. 
For the sake of stability and debugability I think we should disable these, 
and stick with only using -O2, -g, and -Warning flags. --with-cpu=i386 can 
make GCC drop the -mtune down to i386.

I would also like to install Valgrind in /tools so GCC can use it with 
--enable-checking. I haven't checked, but I would imagine the internal 
consistency checks all pass in the recent gcc releases, however the -pie, 
fortify_source, and -fstack options may or may not affect the results. 
Enabling all the internal consistency checks would probably send a GCC 
bootstrap into the 30-50 SBU range, but would also serve to verify we are 
using a solid/stable compiler. This would be best done in the final GCC 
installation, in chapter 6.

Valgrind, and Lint/Splint, can also be used later to test the rest of our 
packages as a part of a base system audit. Some packages are unauditable by 
hlfs, like Glibc, but it would be reasonable to set of goal of auditing the 
suid programs, and document how it was done so users have a reference that 
can be used for blfs packages, like daemons.

And then there's libmudlap. I think it'd be a good idea to link suid programs 
to libmudflap on production systems, but linking the entire system to 
libmudflap would probably make the system unusably slow. However there may be 
some of us willing to devote test systems which run hlfs with all possible 
debugging, either running some network services, or perhaps weekly rebuilds 
with the help of jhalfs in some sort of rc5-like challenge which looks for 
bugs in new packages. It should be easy to add -lmudflap to gcc's specs so 
the entire system is linked to it, for these test systems.

GCC Valgrind tests, and alike, can be relaxed or removed from -stable hlfs 
releases for the sake of keeping the build time sane, but in -unstable it 
would be worth it.

Comments?

robert
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/hlfs-dev/attachments/20060720/fa5adc32/attachment.sig>


More information about the hlfs-dev mailing list