This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Always define USE_PT_GNU_EH_FRAME in crtstuff.c for glibc


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]