bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gcc and gas broken for -mrelax in SH


From: Richard Shann
Subject: gcc and gas broken for -mrelax in SH
Date: Tue, 3 Jul 2001 17:31:41 +0100

With the patch below (kindly supplied by address@hidden and now checked
in) some quite separate problems with the -mrelax option for the SH4 cross
compiler are revealed.
The source file
/********** start of foo.c ****************/

int i;

int foo(void) {
return i;
}

int main(void) {
foo();
return 0;
}

/********** end of foo.c ****************/

When built with -mrelax this fails to link:

sh-hitachi-elf-gcc foo.c -mrelax -v
Reading specs from /vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/specs
Configured with: ../../src/gcc-3.0/configure --target=sh-hitachi-elf
--prefix=/vob/sh-gnu/built --with-newlib
--with-headers=/vob/sh-gnu/src/newlib-20010330/newlib/libc/include/
--enable-languages=c : (reconfigured) ../../src/gcc-3.0/configure
--target=sh-hitachi-elf --prefix=/vob/sh-gnu/built --with-newlib
--with-headers=/vob/sh-gnu/src/newlib-20010330/newlib/libc/include/
--enable-languages=c,c++
Thread model: single
gcc version 3.0
 /vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/cc1 -lang-c -v -D__GNUC__=3
-D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=0 -D__sh__ -D__ELF__ -D__sh__
-D__ELF__ -Acpu=sh -Amachine=sh -D__NO_INLINE__ -D__STDC_HOSTED__=1 -D__sh1__
foo.c -quiet -dumpbase foo.c -mrelax -version -o /var/tmp/cchuUUNg.s
GNU CPP version 3.0 (cpplib) (Hitachi SH)
GNU C version 3.0 (sh-hitachi-elf)
        compiled by GNU C version 2.95.2 19991024 (release).
#include "..." search starts here:
#include <...> search starts here:
 /vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/include
 /vob/sh-gnu/built/sh-hitachi-elf/sys-include
 /vob/sh-gnu/built/sh-hitachi-elf/include
End of search list.
 
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/../../../../sh-hitachi-elf/bin/as
-relax -o /var/tmp/ccvIpmak.o /var/tmp/cchuUUNg.s
 /vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/collect2 -relax
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/crt1.o
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/crti.o
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/crtbegin.o
-L/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0
-L/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/../../../../sh-hitachi-elf/lib
/var/tmp/ccvIpmak.o -lgcc -lc -lgcc
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/crtend.o
/vob/sh-gnu/built/lib/gcc-lib/sh-hitachi-elf/3.0/crtn.o
/var/tmp/ccvIpmak.o: In function `foo':
/var/tmp/ccvIpmak.o(.text+0x4): relocation truncated to fit: R_SH_DIR8WPL text
/var/tmp/ccvIpmak.o: In function `main':
/var/tmp/ccvIpmak.o(.text+0x1c): relocation truncated to fit: R_SH_DIR8WPL text
collect2: ld returned 1 exit status


There seem to be two problems
1) The compiler is failing to detect that the function call can be shortened
(it does not issue the .uses pseudo-directive in the assembler output. Other
versions do detect this.
2) The assembler *is* issuing additional relocations (the R_SH_DIR8WPL) which
are intended to be munged by the relaxation processing in the linker, which
because no R_SH_USES is encountered, remain unmunged. The assembler does this
if it is given the -relax option with an assembler source file created by an
invocation of the compiler with no -mrelax option. That is, it is separate from
the failure of the compiler to spot the opportunity for shortening the function
call.
I guess that as these are two unrelated bugs in different components it will be
best to send this to each of the buglists concerned?

Richard Shann

The gas patch (for reference) is:

Index: gas/config/tc-sh.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-sh.c,v
retrieving revision 1.39
diff -p -r1.39 tc-sh.c
*** tc-sh.c     2001/06/13 16:46:05     1.39
--- tc-sh.c     2001/06/28 15:41:48
*************** sh_frob_section (abfd, sec, ignore)
*** 2340,2348 ****
--- 2340,2354 ----
         We have already adjusted the value of sym to include the
         fragment address, so we undo that adjustment here.  */
        subseg_change (sec, 0);
+ #if 0
        fix_new (symbol_get_frag (sym),
               S_GET_VALUE (sym) - symbol_get_frag (sym)->fr_address,
               4, &abs_symbol, info.count, 0, BFD_RELOC_SH_COUNT);
+ #else
+       fix_new (fscan->fx_frag,
+              S_GET_VALUE (sym) - fscan->fx_frag->fr_address,
+              4, &abs_symbol, info.count, 0, BFD_RELOC_SH_COUNT);
+ #endif
      }
  }



-- 
Richard Shann



reply via email to

[Prev in Thread] Current Thread [Next in Thread]