On Fri, Aug 17, 2012 at 3:14 PM, Joseph S. Myers <jos...@codesourcery.com> wrote: > Bootstrapping cross toolchains using glibc is an unduly complicated > process involving multiple GCC builds and sometimes multiple glibc > builds or glibc header installs. > > Something like the ideal bootstrap process is described at > <http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>. I put > some changes into glibc (for 2.17) to get closer to this process (in > particular, stopping the glibc build from depending on GCC's libgcc_s > or libgcc_eh). This means it is now possible to build glibc using an > initial static-only GCC build with inhibit_libc defined for target > library builds. > > Such a glibc built with such an initial GCC, however, isn't quite > identical to the glibc you get if you then build them full GCC against > the first glibc, then rebuild glibc. It's desirable that it really is > identical so that a second glibc build is completely redundant. > > One cause of differences is that when crtstuff.c is built in the first > inhibit_libc GCC build, USE_PT_GNU_EH_FRAME does not get defined - and > so USE_EH_FRAME_REGISTRY is defined, affecting the crt*.o contents > (which then get linked into various glibc shared libraries). The code > in crtstuff.c has no actual dependence on link.h, so no need for it to > be conditional on inhibit_libc at all. > > Making USE_PT_GNU_EH_FRAME not depend on inhibit_libc, for glibc-using > toolchains, does cause an inconsistency with unwind-dw2-fde-dip.c > where the link.h contents are used so removing the inhibit_libc > dependency is harder. However, I think this inconsistency is OK, > given that inhibit_libc builds for glibc targets are only to be > expected to be useful for bootstrapping, not as the final toolchain > used once glibc has been built (for that, you'll want libgcc_s and > libgcc_eh built against the glibc libraries and headers). > > This patch accordingly adds another case for defining > USE_PT_GNU_EH_FRAME in crtstuff.c: all existing cases are kept as they > are, but this new one is added as well. The logic of > defined(__GLIBC__) || defined(__gnu_linux__) || defined(__GNU__) is > that (a) while __GLIBC__ is usually defined in library headers (which > we may not have at this point), kfreebsd-gnu, knetbsd-gnu and > kopensolaris-gnu define it in GCC; (b) __gnu_linux__ covers exactly > those cases with the Linux kernel where glibc is in use and (c) > __GNU__ covers the GNU Hurd, the remaining case of use of glibc. > > Tested with cross to arm-none-linux-gnueabi that this does indeed fix > various cases where previously rebuilding glibc with the second GCC as > part of a bootstrap process would result in differences from the > first-built glibc, and bootstrapped with no regressions on > x86_64-unknown-linux-gnu as a sanity check. OK to commit? > > With this patch, all the glibc libraries proper - libraries against > which one might link, such as libc.so.6 and libm.so.6 - have identical > disassembly for both builds, whereas they did not all have identical > disassembly before. There are, however, still differences in > miscellaneous .so files used by glibc and programs installed by glibc, > such as libmemusage.so. In that case, at least some differences > result from functions in libgcc.a being hidden in the second GCC build > but not the first static-only build. In my view, the logic for giving > libgcc functions hidden visibility should be the same whether or not a > shared libgcc is being built. (This does mean that in the static-only > case, objects from .S files would need the _s.o versions built for use > in generating the list of symbols to hide.) Comments? > > 2012-08-17 Joseph Myers <jos...@codesourcery.com> > > * crtstuff.c (USE_PT_GNU_EH_FRAME): Define for systems using glibc > even if inhibit_libc. > > Index: libgcc/crtstuff.c > =================================================================== > --- libgcc/crtstuff.c (revision 190491) > +++ libgcc/crtstuff.c (working copy) > @@ -1,7 +1,7 @@ > /* Specialized bits of code needed to support construction and > destruction of file-scope objects in C++ code. > Copyright (C) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 > - 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011 > + 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2010, 2011, 2012 > Free Software Foundation, Inc. > Contributed by Ron Guilmette (r...@monkeys.com). > > @@ -113,6 +113,19 @@ > # define USE_PT_GNU_EH_FRAME > # endif > #endif > + > +#if defined(OBJECT_FORMAT_ELF) \ > + && !defined(OBJECT_FORMAT_FLAT) \ > + && defined(HAVE_LD_EH_FRAME_HDR) \ > + && !defined(CRTSTUFFT_O) \ > + && (defined(__GLIBC__) || defined(__gnu_linux__) || defined(__GNU__)) > +/* On systems using glibc, an inhibit_libc build of libgcc is only > + part of a bootstrap process. Build the same crt*.o as would be > + built with headers present, so that it is not necessary to build > + glibc more than once for the bootstrap to converge. */ > +# define USE_PT_GNU_EH_FRAME > +#endif > +
Looking at the #if just before this one, it looks like you've omitted the checks for a version of glibc before 2.2.2. Also I'm not sure how this will play out with uClibc: it seems like it might always turn on USE_PT_GNU_EH_FRAME, which might or might not be OK. These would not be issues if you added && defined(inhibit_libc). Did you consider that? > With this patch, all the glibc libraries proper - libraries against > which one might link, such as libc.so.6 and libm.so.6 - have identical > disassembly for both builds, whereas they did not all have identical > disassembly before. There are, however, still differences in > miscellaneous .so files used by glibc and programs installed by glibc, > such as libmemusage.so. In that case, at least some differences > result from functions in libgcc.a being hidden in the second GCC build > but not the first static-only build. In my view, the logic for giving > libgcc functions hidden visibility should be the same whether or not a > shared libgcc is being built. (This does mean that in the static-only > case, objects from .S files would need the _s.o versions built for use > in generating the list of symbols to hide.) Comments? I agree that this seems clearly desirable. Ian
