Bug 30726 - bootstrap support for x86_64-*-solaris2.10
Summary: bootstrap support for x86_64-*-solaris2.10
Status: RESOLVED DUPLICATE of bug 39150
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.1.2
: P3 enhancement
Target Milestone: ---
Assignee: Rainer Orth
URL:
Keywords:
: 34775 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-02-07 07:38 UTC by Peter Bray
Modified: 2010-04-28 20:54 UTC (History)
4 users (show)

See Also:
Host: i386-*-solaris2.10
Target: x86_64-*-solaris2.10
Build:
Known to work:
Known to fail:
Last reconfirmed: 2010-04-28 20:54:01


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Bray 2007-02-07 07:38:12 UTC
Request: Add x86_64-*-solaris2.10 support to the bootstrap process.

Additional Info:
While i386-*-solaris2.10 builds a compiler capable of build x86_64/amd64 object files with the -m64 command line option, it was not possible (for me) to build a compiler that default to 64-bit code generation for this platform. 

Support for this is available on Solaris/SPARC with sparc-sun-solaris2* vs sparc64-sun-solaris2*, and all the hard work has been done (in that code generation works) but I was unable to find the correct of flags to change in
gcc/config.gcc and gcc/config/i386/* to make 64-bit the default compilation mode of the generated compiler.

I have been working at this myself for two days now and always seem to run into problems, with either the generated compiler reverting to generating 32-bit code, the assembler rejecting the generated code (various reasons, probably related to incorrect flags being passed to 'as'), or 98% files generated in 64-bit mode and one or two being generated in 32-bit causing link errors.

To-date I have made new target in gcc/config.gcc for x86_64-*-solaris2.10 based on the existing i*86-*-solaris2* code and tried modifying gcc/config/i386-sol10.h to change the default multi-lib. Also I have looked at TARGET_64BIT and tried setting TARGET_64BIT_DEFAULT by hacking the biarch.? file.

Suggestions / Pointers / Patches I can could use or test would be greatly appreciated!

Many thanks in Advance,
Peter Bray
Sydney, Australia

PS: Test system - Sun Ultra 40 (AMD Opteron 280) running Solaris 10 11/06,
    using gcc-4.1.2rc1 (20060128) and /usr/sfw/bin/{gcc,gas} and Sun's "ld"

PPS: To Mark and the 4.1.2 release team, I can confirm gcc-4.1.2rc1 builds fine for sparc-sun-solaris2.10 (with and without --cpu=v9), sparcv9-sun-solaris2.10 and i386-pc-solaris2.10. The SPARC variant had to be built with Sun as/ld as the recommended combination (several sources) of GNU as (2.17) and Sun ld results in the DWARF2 debug(-g)/ld align bug is Sun's ld, according to opensolaris.org snv53 has a fix for this issue, but that is not available as a patch to Solaris 10 (yet).
Comment 1 Eric Botcazou 2007-02-07 07:50:54 UTC
> The SPARC variant had to be built with Sun as/ld as the recommended
> combination (several sources) of GNU as (2.17) and Sun ld results in
> the DWARF2 debug(-g)/ld align bug is Sun's ld,

A fix is available in the CVS tree of GNU binutils (2.17.x, 2.18).
Comment 2 Fabian Groffen 2008-01-13 19:29:33 UTC
*** Bug 34775 has been marked as a duplicate of this bug. ***
Comment 3 Fabian Groffen 2008-01-13 19:30:33 UTC
In bug #34775 I've attached a configuration patch that works for me.
Comment 4 Peter Bray 2008-01-22 23:49:36 UTC
As the originator of this request I can verify that the patch provided by Fabian Groffen as part of Bug 34775 is functional and works as advertised. I believe the patch should be reviewed and integrated.

The patch does required his associated patch to binutils-2.18 has documented at http://sourceware.org/bugzilla/show_bug.cgi?id=5606

Testing Environment: Sun Solaris 10 Update 4 running on Sun Ultra 40 M2, with a single patch (mentioned above) applied to binutils-2.18 released tar ball. Bootstrapping compiler was gcc-4.1.2. GCC testsuite not run.
Comment 5 Rainer Orth 2010-04-28 20:54:01 UTC
Mine.
Comment 6 Rainer Orth 2010-04-28 20:54:57 UTC

*** This bug has been marked as a duplicate of 39150 ***