From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1178 invoked by alias); 16 May 2003 15:16:00 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 1164 invoked by uid 71); 16 May 2003 15:16:00 -0000 Date: Fri, 16 May 2003 15:16:00 -0000 Message-ID: <20030516151600.1163.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Eric Botcazou Subject: Re: bootstrap/10805: [sun-solaris2.7] relocation error when creating sparcv9/libgcc_s.so.1 Reply-To: Eric Botcazou X-SW-Source: 2003-05/txt/msg01849.txt.bz2 List-Id: The following reply was made to PR bootstrap/10805; it has been noted by GNATS. From: Eric Botcazou To: Marc Glisse Cc: , , Subject: Re: bootstrap/10805: [sun-solaris2.7] relocation error when creating sparcv9/libgcc_s.so.1 Date: Fri, 16 May 2003 17:11:49 +0200 > One difference is that I do not have this patch. I will try to install it > as soon as I can. For the bootstrap compiler, I used: > cc: Sun WorkShop 6 2000/04/07 C 5.1 > gcc (GCC) 3.2.2 > > And both give the same result. Steven Christensen tried with GCC 3.2.3 too and same result. > > Could you determine at which stage bootstrap fails? > > If the compiler's C source files were latterly compiled by cc, it's > > stage1. If they were compiled by stage1/xgcc, it's stage2 and if they > > were compiled by stage2/xgcc, it's stage3. > > first there is a lot of gcc. Then this gcc/xgcc. Actually this should be > clearer: > > make[3]: *** [sparcv9/libgcc_s_sparcv9.so] Error 1 > make[3]: Leaving directory `/global/lavarenne/download/gcc-3.3/gcc' > make[2]: *** [stmp-multilib] Error 2 > make[2]: Leaving directory `/global/lavarenne/download/gcc-3.3/gcc' > make[1]: *** [stage1_build] Error 2 > make[1]: Leaving directory `/global/lavarenne/download/gcc-3.3/gcc' > make: *** [bootstrap] Error 2 Ok, it's stage1. Given that we have the same problem with 3 different bootstrap compilers, I'm inclined to suspect the Sun assembler. > With the messages: > > ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o: > symbol : offset 0xffffffff7ec133e7 is non-aligned > > ld: fatal: relocation error: R_SPARC_64: file libgcc/sparcv9/_muldi3.o: > symbol : offset 0xffffffff7ec133eb is non-aligned > > ld: fatal: relocation error: R_SPARC_64: file libgcc/sparcv9/_muldi3.o: > symbol : offset 0xffffffff7ec133f3 is non-aligned > > ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o: > symbol : offset 0xffffffff7ec13867 is non-aligned > > ld: fatal: relocation error: R_SPARC_32: file libgcc/sparcv9/_muldi3.o: > symbol : offset 0xffffffff7ec14a2f is non-aligned > > But about all the .o give this kind of messages. I think the relocations type R_SPARC_32 and R_SPARC_64 are wrong here because the offsets are rightfully unaligned. The same dump on my Solaris 7 box shows only R_SPARC_UA32 and R_SPARC_UA64 types which are described by the Sun docs as follows: R_SPARC_UA32 This relocation type resembles R_SPARC_32, except that it refers to an unaligned word. That is, the word to be relocated must be treated as four separate bytes with arbitrary alignment, not as a word aligned according to the architecture requirements. -- Eric Botcazou