[Bug lto/50935] New: All slim LTO tests FAIL on 32-bit Solaris

[Bug lto/50935] New: All slim LTO tests FAIL on 32-bit Solaris

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

             Bug #: 50935
           Summary: All slim LTO tests FAIL on 32-bit Solaris
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
                CC: jh@suse.cz
              Host: *-*-solaris2*
            Target: *-*-solaris2*
             Build: *-*-solaris2.*


All slim LTO tests fail on 32-bit Solaris with gld 2.21.1 and 2.21.90:

spawn /vol/gcc/obj/regression/trunk/11-gcc-gas-gld/build/gcc/xgcc
-B/vol/gcc/obj/regression/trunk/11-gcc-gas-gld/build/gcc/
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1.c
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/builtins/20010124-1-lib.c
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c
-w -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -lm -o
/var/gcc/regression/trunk/11-gcc-gas-gld/build/gcc/testsuite/gcc5/20010124-1.x7

/usr/lib/crt1.o: In function `_start':

fsr.s:(.text+0x7f): undefined reference to `main'

collect2: error: ld returned 1 exit status

compiler exited with status 1
output is:
/usr/lib/crt1.o: In function `_start':

fsr.s:(.text+0x7f): undefined reference to `main'

collect2: error: ld returned 1 exit status


FAIL: gcc.c-torture/execute/builtins/20010124-1.c compilation,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
UNRESOLVED: gcc.c-torture/execute/builtins/20010124-1.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 

If turns out that there's a range of issues here:

* Unlike fat LTO, which needs only a gld or gold binary with linker plugin
  support, slim LTO needs corresponding binutils nm, ar, and ranlib.  For a
  64-bit default gcc, one needs 64-bit nm etc. in particular, where otherwise
  there would be no reason at all to have 64-bit commands.

* For 32-bit binutils, BFD_SUPPORTS_PLUGINS is off by default, as described
  in config/largefile.m4:

changequote(,)dnl
  sparc-*-solaris*|i[3-7]86-*-solaris*)
changequote([,])dnl
    # On native 32bit sparc and ia32 solaris, large-file and procfs support
    # are mutually exclusive; and without procfs support, the bfd/ elf module
    # cannot provide certain routines such as elfcore_write_prpsinfo
    # or elfcore_write_prstatus.  So unless the user explicitly requested
    # large-file support through the --enable-largefile switch, disable
    # large-file support in favor of procfs support.

For those reasons, it's much more work to provide a working slim LTO
environment
(and that's not only true on Solaris, but also on Linux where I often test a
recent gas/gld which is newer than what's bundled with the distribution), so
the testsuite *must* test for working slim LTO support before using 
-fno-fat-lto-objects, otherwise one gets hundreds of testsuite failures.

  Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-11-01
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-01 09:27:20 UTC ---
Confirmed.  Can you try writing a dg-effective-target test?

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-02 09:18:04 UTC ---
> --- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-11-01 09:27:20 UTC ---
> Confirmed.  Can you try writing a dg-effective-target test?

Sure, that's my plan once I'm done with the libgcc patches.

    Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bonzini at gnu dot org
   Target Milestone|---                         |4.7.0

--- Comment #3 from Rainer Orth <ro at gcc dot gnu.org> 2011-11-21 16:41:54 UTC ---
It took me a while, but the issue turned out to be different:

* Toplevel config/largefile.m4 disables largefile support for 32-bit Solaris,
  and both bfd and ld use ACX_LARGEFILE.

* On the other hand, gcc enables largefile support by default, thus the
lto-plugin
  is built with it.

* The resulting ld often fails in strange ways, as expected.

* If I build binutils with --enable-largefile, the vast majority of slim LTO
  tests suddenly pass, even when binutils ar, nm, and ranlib are nowhere in
  PATH, and are not plugin-enabled by default.

I'm undecided how to deal with this: the largefile disabling in largefile.m4 is
only for the benefit of procfs (thus gdb), but bfd/ld cannot know if they are
built in a combined tree.  ld cannot easily check if a plugin is largefile
enabled (this would probably be highly system-dependent), and there is no
guarantee that a plugin uses I/O functions at all.  Maybe the lto-plugin could
perform some check with dlsym (for open64?)?

Alternatiely, one could simply document the problem in install.texi and be done
with it.

Thoughts?
  Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-21 16:50:54 UTC ---
I forgot: while one could use ACX_LARGEFILE everywhere in GCC (and I
tried that using --disable-largefile when configuring gcc works with a
default-configured gld), I'd rather not cripple all of gcc for the
benefit of the lto-plugin.

Using the macro in lto-plugin alone doesn't work either: the plugin is
linked with libiberty, and gld SEGVs all over the place if libiberty
isn't built with largefile support.  Since libiberty is also linked into
all the compiler executables, we're effectively back to using
ACX_LARGEFILE/--disable-largefile everywhere.

    Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[bonzini at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

--- Comment #5 from Paolo Bonzini <bonzini at gnu dot org> 2011-11-21 17:25:20 UTC ---
What's exactly the problem with gdb that requires disabling largefiles?

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-11-21 17:30:21 UTC ---
> --- Comment #5 from Paolo Bonzini <bonzini at gnu dot org> 2011-11-21 17:25:20 UTC ---
> What's exactly the problem with gdb that requires disabling largefiles?

gdb (and only gdb AFAIK) uses procfs, and Solaris procfs doesn't support
a largefile environment, no idea why?

<sys/procfs.h> has

#if !defined(_LP64) && _FILE_OFFSET_BITS == 64
#error  "Cannot use procfs in the large file compilation environment"
#endif

    Rainer

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.7.1

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-22 08:27:22 UTC ---
GCC 4.7.0 is being released, adjusting target milestone.

[Bug lto/50935] All slim LTO tests FAIL on 32-bit Solaris

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50935

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.1                       |---