This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc
- From: Ian Lance Taylor <iant at google dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, ian at airs dot com
- Date: Fri, 17 Aug 2012 16:53:00 -0700
- Subject: Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc
- References: <Pine.LNX.4.64.1208172212010.2674@digraph.polyomino.org.uk>
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