Fix HEAD build on amd64

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fix HEAD build on amd64

Daniel Jacobowitz-2
The unconditional provision of __EH_FRAME_BEGIN__ caused a problem on amd64,
because amd64 also always generates unwind tables.  soinit.os had both
a manually generated .eh_frame entry and a compiler-generated one; one
of the two was writable and the other not.  In GCC 4.0 this causes an
ICE and in GCC HEAD (4.2) a polite error.

I also noticed that the symbol was unused; if it's to make it to the
output file, it had better be marked used.  There's a chance
that some future version of GCC will not put __EH_FRAME_BEGIN__
before the unwind data for __libc_fini, but that won't be a tragedy,
just a little bit odd - __FRAME_END__ is the important one.

__FRAME_END__ updated likewise for consistency.

--
Daniel Jacobowitz
CodeSourcery

2006-02-24  Daniel Jacobowitz  <[hidden email]>

        * config.h.in (HAVE_EH_FRAME_READONLY): New template.
        * configure.in: Check for read-only .eh_frame.
        * elf/sofini.c (__FRAME_END__): Mark const if
        HAVE_EH_FRAME_READONLY.
        * elf/soinit.c (__EH_FRAME_BEGIN__): Likewise.  Also mark used.

Index: config.h.in
===================================================================
RCS file: /big/fsf/rsync/glibc/libc/config.h.in,v
retrieving revision 1.78
diff -u -p -r1.78 config.h.in
--- config.h.in 22 Feb 2006 02:09:03 -0000 1.78
+++ config.h.in 24 Feb 2006 16:08:56 -0000
@@ -105,6 +105,9 @@
 /* Define if the compiler supports __attribute__((tls_model(""))).  */
 #undef HAVE_TLS_MODEL_ATTRIBUTE
 
+/* Define if .eh_frame additions should be const.  */
+#undef HAVE_EH_FRAME_READONLY
+
 /* Define if the regparm attribute shall be used for local functions
    (gcc on ix86 only).  */
 #undef USE_REGPARMS
Index: configure.in
===================================================================
RCS file: /big/fsf/rsync/glibc/libc/configure.in,v
retrieving revision 1.455
diff -u -p -r1.455 configure.in
--- configure.in 22 Feb 2006 02:09:03 -0000 1.455
+++ configure.in 24 Feb 2006 16:08:57 -0000
@@ -1823,6 +1823,25 @@ EOF
   fi
 fi
 
+dnl Check whether manual additions to .eh_frame should be const.  If not,
+dnl this will either error or ICE depending on the GCC version.
+AC_CACHE_CHECK([for read-only .eh_frame], libc_cv_gcc_eh_frame_readonly, [dnl
+cat > conftest.c <<\EOF
+const char baz[] __attribute__ ((section (".eh_frame"))) = { 0 };
+void zab (void)
+{ }
+EOF
+if AC_TRY_COMMAND([${CC-cc} $CFLAGS $CPPFLAGS -S -fexceptions conftest.c >&AS_MESSAGE_LOG_FD]); then
+  libc_cv_gcc_eh_frame_readonly=yes
+else
+  libc_cv_gcc_eh_frame_readonly=no
+fi
+rm -f conftest*])
+if test "$libc_cv_gcc_eh_frame_readonly" = yes; then
+  AC_DEFINE(HAVE_EH_FRAME_READONLY)
+fi
+  
+
 dnl Check whether we have the gd library available.
 AC_MSG_CHECKING(for libgd)
 if test "$with_gd" != "no"; then
Index: elf/sofini.c
===================================================================
RCS file: /big/fsf/rsync/glibc/libc/elf/sofini.c,v
retrieving revision 1.5
diff -u -p -r1.5 sofini.c
--- elf/sofini.c 22 Feb 2006 02:09:03 -0000 1.5
+++ elf/sofini.c 24 Feb 2006 16:08:57 -0000
@@ -12,6 +12,9 @@ static void (*const __DTOR_END__[1]) (vo
    this would be the 'length' field in a real FDE.  */
 
 typedef unsigned int ui32 __attribute__ ((mode (SI)));
-static ui32 __FRAME_END__[1]
-     __attribute__ ((used, section (".eh_frame")))
+static ui32
+#ifdef HAVE_EH_FRAME_READONLY
+     const
+#endif
+     __FRAME_END__[1] __attribute__ ((used, section (".eh_frame")))
      = { 0 };
Index: elf/soinit.c
===================================================================
RCS file: /big/fsf/rsync/glibc/libc/elf/soinit.c,v
retrieving revision 1.13
diff -u -p -r1.13 soinit.c
--- elf/soinit.c 22 Feb 2006 02:09:03 -0000 1.13
+++ elf/soinit.c 24 Feb 2006 16:08:57 -0000
@@ -20,8 +20,11 @@ run_hooks (void (*const list[]) (void))
     (**list) ();
 }
 
-static char __EH_FRAME_BEGIN__[]
-     __attribute__ ((section (".eh_frame")))
+static char
+#ifdef HAVE_EH_FRAME_READONLY
+     const
+#endif
+     __EH_FRAME_BEGIN__[] __attribute__ ((used, section (".eh_frame")))
      = { };
 
 /* This function will be called from _init in init-first.c.  */
Reply | Threaded
Open this post in threaded view
|

Re: Fix HEAD build on amd64

Roland McGrath
Why shouldn't .eh_frame always be read-only?
Reply | Threaded
Open this post in threaded view
|

Re: Fix HEAD build on amd64

Daniel Jacobowitz-2
On Fri, Feb 24, 2006 at 01:37:30PM -0800, Roland McGrath wrote:
> Why shouldn't .eh_frame always be read-only?

It depends on the encoding selected by GCC.  The code in dwarf2out.c
suggests that there is at least one architecture, somewhere, which
uses DW_EH_PE_absptr or DW_EH_PE_aligned even for PIC code, and various
linker versions where it must conservatively be writable.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: Fix HEAD build on amd64

Daniel Jacobowitz-2
On Fri, Feb 24, 2006 at 04:50:09PM -0500, Daniel Jacobowitz wrote:
> On Fri, Feb 24, 2006 at 01:37:30PM -0800, Roland McGrath wrote:
> > Why shouldn't .eh_frame always be read-only?
>
> It depends on the encoding selected by GCC.  The code in dwarf2out.c
> suggests that there is at least one architecture, somewhere, which
> uses DW_EH_PE_absptr or DW_EH_PE_aligned even for PIC code, and various
> linker versions where it must conservatively be writable.

... but the odds aren't too bad that none of this matters for the
purposes of glibc builds.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: Fix HEAD build on amd64

Roland McGrath
In reply to this post by Daniel Jacobowitz-2
> On Fri, Feb 24, 2006 at 01:37:30PM -0800, Roland McGrath wrote:
> > Why shouldn't .eh_frame always be read-only?
>
> It depends on the encoding selected by GCC.  The code in dwarf2out.c
> suggests that there is at least one architecture, somewhere, which
> uses DW_EH_PE_absptr or DW_EH_PE_aligned even for PIC code, and various
> linker versions where it must conservatively be writable.

This is just for our own .so builds in libc, and none of them need that.
What's not clear to me yet is if there are GCC configurations that will
barf at compile/link time on a read-only .eh_frame section.  If so, we'll
go with your configure check I guess.  If not, it can just always be const.


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: Fix HEAD build on amd64

Daniel Jacobowitz-2
On Fri, Feb 24, 2006 at 02:09:13PM -0800, Roland McGrath wrote:

> > On Fri, Feb 24, 2006 at 01:37:30PM -0800, Roland McGrath wrote:
> > > Why shouldn't .eh_frame always be read-only?
> >
> > It depends on the encoding selected by GCC.  The code in dwarf2out.c
> > suggests that there is at least one architecture, somewhere, which
> > uses DW_EH_PE_absptr or DW_EH_PE_aligned even for PIC code, and various
> > linker versions where it must conservatively be writable.
>
> This is just for our own .so builds in libc, and none of them need that.
> What's not clear to me yet is if there are GCC configurations that will
> barf at compile/link time on a read-only .eh_frame section.  If so, we'll
> go with your configure check I guess.  If not, it can just always be const.

With current vintage binutils, always const is probably fine.

--
Daniel Jacobowitz
CodeSourcery