gas bug (sparclite-coff xgcc)

John Stebbins
Fri Oct 25 08:21:00 GMT 2002

This is technically not a bug with gcc, but shows when creating
a sparc-coff cross compiler.  I posted to bug-bintutils a couple of
days ago and have seen no activity regarding this, so I thought I
would cross post here to see if anyone had any ideas.

I've been attempting to create a sparclite-coff gcc cross compiler and
have run up against what appears to be a bug in gas.

I have sources for:

I follow the directions to do a one-step build of gcc, binutils, and
libs. This involves creating a few links from gcc source dir to binutils
and newlib source dirs.

My host system is i686-pc-linux-gnu.

I configure gcc build like this:
../gcc-3.2/configure --prefix=/usr/local/sparc 
--program-prefix=sparclite-coff- --with-local-prefix=/usr/local/sparc
--disable-shared --with-stabs --disable-threads --enable-target-optspace
--enable-language=c,c++ --disable-nls --with-newlib 
--target=sparclite-coff -v

make all

binutils are built (including gas) and then it starts building libgcc.
While compiling (with xgcc) gcc/libgcc2.c it fails with message:

/tmp/cch53SPl.s: Assembler messages:
/tmp/cch53SPl.s:678: Error: internal error: can't export reloc type 69
/tmp/cch53SPl.s:694: Error: internal error: can't export reloc type 69

Here is the xgcc command line that caused this error:

-B/home/stebbins/PubSrc/sparc-tools/build-3.2/gcc/ -nostdinc
-isystem /home/stebbins/PubSrc/sparc-tools/build-3.2/sparclite-coff/newlib/targ-include 
-isystem /home/stebbins/PubSrc/sparc-tools/gcc-3.2/newlib/libc/include 
-B/usr/local/sparc/sparclite-coff/bin/ -B/usr/local/sparc/sparclite-coff/lib/ 
-isystem /usr/local/sparc/sparclite-coff/include 
-L/home/stebbins/PubSrc/sparc-tools/build-3.2/ld -O2  
-DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -isystem ./include   -g  -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc-3.2/gcc 
-I../../gcc-3.2/gcc/. -I../../gcc-3.2/gcc/config -I../../gcc-3.2/gcc/../include  
-DL_divdi3 -c ../../gcc-3.2/gcc/libgcc2.c -fexceptions -fnon-call-exceptions 
-o libgcc/./_divdi3.o

To get a better look at things I recompile with -S flag to generate the
assembly file and have a look at lines 678 and 694.  Here is what I see

676	.LASFDE1:
677        .uaword .LASFDE1-.Lframe1
678        .uaword .LFB1                 <----internal error is here
679        .uaword .LFE1-.LFB1
680        .byte   0x4


692	.LASFDE3:
693        .uaword .LASFDE3-.Lframe1
694        .uaword .LFB2                 <----internal error is here
695        .uaword .LFE2-.LFB2
696        .byte   0x4

Notice the similarity between the lines that cause the errors.  I went
back and compiled up a few other files that succeeded to build using the
-S flag to generate assembly and looked for other .uaword directives. 
None of the files that succeed have similar code.

After checking for bug reports and not finding any that match my
problem, I started backing off to older versions of binutils.  The
problem exists in 2.13 and 2.12, but does not exist in 2.11.

I also verified that this problem exists when building a gcc-3.1.1 cross

I don't subscribe to the list, so if anyone has a quick fix for this, I
would appreciate it if you would respond direct to me.


John Stebbins <>
John Stebbins <>

More information about the Gcc-bugs mailing list