Stability and debugging
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the hlfs-dev