Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc

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  <joseph@codesourcery.com>

	* crtstuff.c (USE_PT_GNU_EH_FRAME): Define for systems using glibc
	even if inhibit_libc.

On Fri, Aug 17, 2012 at 3:14 PM, Joseph S. Myers
<joseph@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  <joseph@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 (rfg@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