All of lore.kernel.org
 help / color / mirror / Atom feed
* RE: Differing results from cross and native compilers
@ 2006-09-19 16:57 ` Eric DeVolder
  0 siblings, 0 replies; 15+ messages in thread
From: Eric DeVolder @ 2006-09-19 16:57 UTC (permalink / raw)
  To: Thiemo Seufer; +Cc: linux-mips

[-- Attachment #1: Type: text/plain, Size: 6988 bytes --]

Yes, it appears to me that the compiler (cc1) and assembler (as) invocations are the same. I've included the "-v" output of each below for reference. Furthermore, the -save-temps output .i files are effectively the same (differences due to cross vs. native paths, but that is it). Nonetheless, the output assembly source still contains differences!
 
I'm curious if anybody examined the output of a cross and native toolchain of the same (recent) version?
 
Eric
 
 
0:~$ diff -wbup cross.s native.s
--- cross.s 2006-09-19 11:38:54.000000000 -0500
+++ native.s     2006-09-19 11:39:07.000000000 -0500
@@ -17,24 +17,20 @@ main:
        .fmask  0x00000000,0
        .set    noreorder
        .cpload $25
-       .set    nomacro
-
+       .set    reorder
        addiu   $sp,$sp,-32
        sw      $31,24($sp)
        .cprestore      16
-       lw      $4,%got($LC0)($28)
-       lw      $25,%call16(printf)($28)
-       nop
-       jalr    $25
-       addiu   $4,$4,%lo($LC0)
-
-       lw      $28,16($sp)
+       la      $4,$LC0
+       jal     printf
        lw      $31,24($sp)
        subu    $2,$0,$2
+       .set    noreorder
+       .set    nomacro
        j       $31
        addiu   $sp,$sp,32
-
        .set    macro
        .set    reorder
+
        .end    main
        .ident  "GCC: (GNU) 3.4.4"

For good measure, here's the assembly output from the cross compiler:
 
0:~$ more cross.s
  .file 1 "t.c"
  .section .mdebug.abi32
  .previous
  .abicalls
  .section  .rodata.str1.4,"aMS",@progbits,1
  .align  2
$LC0:
  .ascii  "Hello, World!\n\000"
  .text
  .align  2
  .globl  main
  .ent  main
  .type main, @function
main:
  .frame  $sp,32,$31    # vars= 0, regs= 1/0, args= 16, gp= 8
  .mask 0x80000000,-8
  .fmask  0x00000000,0
  .set  noreorder
  .cpload $25
  .set  nomacro
  addiu $sp,$sp,-32
  sw  $31,24($sp)
  .cprestore  16
  lw  $4,%got($LC0)($28)
  lw  $25,%call16(printf)($28)
  nop
  jalr  $25
  addiu $4,$4,%lo($LC0)
  lw  $28,16($sp)
  lw  $31,24($sp)
  subu  $2,$0,$2
  j $31
  addiu $sp,$sp,32
  .set  macro
  .set  reorder
  .end  main
  .ident  "GCC: (GNU) 3.4.4"

And here is the cross and native screen capture due to -v:
 
==== cross ====
0:~$ mipsel-unknown-linux-gnu-gcc -v -save-temps -O2 -c /opt/oe/target/root/t.c  -o obj2.o
Reading specs from /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/specs
Configured with: /home/edevolder/downloads/crosstool-0.42/build/mipsel-unknown-linux-gnu/gcc-3.4.4-glibc-2.3.6/gcc-3.4.4/configure --target=mipsel-unknown-linux-gnu --host=x86_64-host_unknown-linux-gnu --prefix=/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu --with-sysroot=/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/sys-root --with-local-prefix=/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/sys-root --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 3.4.4
 /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/libexec/gcc/mipsel-unknown-linux-gnu/3.4.4/cc1 -E -quiet -v /opt/oe/target/root/t.c -O2 -o t.i
ignoring nonexistent directory "/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/sys-root/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/sys-root/include"
ignoring nonexistent directory "/opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/../../../../mipsel-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/include
 /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/mipsel-unknown-linux-gnu/sys-root/usr/include
End of search list.
 /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/libexec/gcc/mipsel-unknown-linux-gnu/3.4.4/cc1 -fpreprocessed t.i -quiet -dumpbase t.c -auxbase-strip obj2.o -O2 -version -o t.s
GNU C version 3.4.4 (mipsel-unknown-linux-gnu)
        compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-54).
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=126001
 /opt/crosstool/gcc-3.4.4-glibc-2.3.6/mipsel-unknown-linux-gnu/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/../../../../mipsel-unknown-linux-gnu/bin/as -EL -O2 -no-mdebug -32 -v -KPIC -o obj2.o t.s
GNU assembler version 2.15 (mipsel-unknown-linux-gnu) using BFD version 2.15
 
=== native ===
root@db1200:~# gcc -v -save-temps -O2 -c t.c -o obj1.o
Reading specs from /usr/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/specs
Configured with: /home/edevolder/downloads/crosstool-0.42/build/mipsel-unknown-linux-gnu/gcc-3.4.4-glibc-2.3.6/gcc-3.4.4/configure --build=x86_64-build_unknown-linux-gnu --target=mipsel-unknown-linux-gnu --host=mipsel-unknown-linux-gnu --prefix=/usr --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long
Thread model: posix
gcc version 3.4.4
 /usr/libexec/gcc/mipsel-unknown-linux-gnu/3.4.4/cc1 -E -quiet -v t.c -O2 -o t.iignoring nonexistent directory "/usr/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/../../../../mipsel-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/include
 /usr/include
End of search list.
 /usr/libexec/gcc/mipsel-unknown-linux-gnu/3.4.4/cc1 -fpreprocessed t.i -quiet -dumpbase t.c -auxbase-strip obj1.o -O2 -version -o t.s
GNU C version 3.4.4 (mipsel-unknown-linux-gnu)
        compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=31868
 /usr/lib/gcc/mipsel-unknown-linux-gnu/3.4.4/../../../../mipsel-unknown-linux-gnu/bin/as -EL -O2 -no-mdebug -32 -v -KPIC -o obj1.o t.s
GNU assembler version 2.15 (mipsel-unknown-linux-gnu) using BFD version 2.15


________________________________

From: Thiemo Seufer [mailto:ths@networkno.de]
Sent: Tue 9/19/2006 11:05 AM
To: Eric DeVolder
Cc: linux-mips@linux-mips.org
Subject: Re: Differing results from cross and native compilers



Eric DeVolder wrote:
[snip]
> I would have thought that for this simple example I'd get identical
> results. For reasons I have yet to figure out, the cross compiler is
> finding better optimizations than the native, though both are the
> same gcc version. I checked the specs files, and the two are identical
> other than the "cross_compile" setting.

Have you checked (with -v) if the assembler gets the same optimisations
in both cases, and/or (with -save-temps) where in the compile things
start to diverge?


Thiemo



[-- Attachment #2: Type: text/html, Size: 10404 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread
* RE: Differing results from cross and native compilers
@ 2006-09-21 14:53 ` Eric DeVolder
  0 siblings, 0 replies; 15+ messages in thread
From: Eric DeVolder @ 2006-09-21 14:53 UTC (permalink / raw)
  To: Jim Wilson; +Cc: Thiemo Seufer, linux-mips

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

oops...ignore the cut-n-paste below, this was from the cross compile which in fact shows using gnu assembler and explicit reloc support...eric 

________________________________

From: Eric DeVolder
Sent: Thu 9/21/2006 9:26 AM
To: Jim Wilson
Cc: Thiemo Seufer; linux-mips@linux-mips.org
Subject: RE: Differing results from cross and native compilers


Thanks Jim, you hit the nail on the head!
 
gcc/config.log:target_cpu_default='(MASK_GAS)|MASK_EXPLICIT_RELOCS'
gcc/config.status:s,@target_cpu_default@,(MASK_GAS)|MASK_EXPLICIT_RELOCS,;t t
gcc/Makefile:target_cpu_default=(MASK_GAS)|MASK_EXPLICIT_RELOCS

So yes, something went awry and the configure stage didn't think gas was in use...
 
Eric 

________________________________

From: Jim Wilson [mailto:wilson@specifix.com]
Sent: Tue 9/19/2006 6:22 PM
To: Eric DeVolder
Cc: Thiemo Seufer; linux-mips@linux-mips.org
Subject: RE: Differing results from cross and native compilers



On Tue, 2006-09-19 at 09:57 -0700, Eric DeVolder wrote:

> -       lw      $4,%got($LC0)($28)
> +       la      $4,$LC0

The difference here is -mexplicit-relocs, which is the default for the
first one (cross) but not the second one (native).

The explicit-reloc support is enabled by a run-time configure test,
which tries to run the assembler to see if you have a new enough version
of GNU as that supports the necessary assembler reloc syntax.
Apparently this is going wrong with the native build.  Perhaps you have
a different binutils version, or perhaps there is a problem with your
PATH, or perhaps binutils and gcc weren't configured with the same
prefix, etc.

If you have the build trees, you can look at the gcc/config.h files and
note that one has HAVE_AS_EXPLICIT_RELOCS defined and the other doesn't.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com







[-- Attachment #2: Type: text/html, Size: 3052 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread
* RE: Differing results from cross and native compilers
@ 2006-09-21 14:26 ` Eric DeVolder
  0 siblings, 0 replies; 15+ messages in thread
From: Eric DeVolder @ 2006-09-21 14:26 UTC (permalink / raw)
  To: Jim Wilson; +Cc: Thiemo Seufer, linux-mips

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Thanks Jim, you hit the nail on the head!
 
gcc/config.log:target_cpu_default='(MASK_GAS)|MASK_EXPLICIT_RELOCS'
gcc/config.status:s,@target_cpu_default@,(MASK_GAS)|MASK_EXPLICIT_RELOCS,;t t
gcc/Makefile:target_cpu_default=(MASK_GAS)|MASK_EXPLICIT_RELOCS

So yes, something went awry and the configure stage didn't think gas was in use...
 
Eric 

________________________________

From: Jim Wilson [mailto:wilson@specifix.com]
Sent: Tue 9/19/2006 6:22 PM
To: Eric DeVolder
Cc: Thiemo Seufer; linux-mips@linux-mips.org
Subject: RE: Differing results from cross and native compilers



On Tue, 2006-09-19 at 09:57 -0700, Eric DeVolder wrote:

> -       lw      $4,%got($LC0)($28)
> +       la      $4,$LC0

The difference here is -mexplicit-relocs, which is the default for the
first one (cross) but not the second one (native).

The explicit-reloc support is enabled by a run-time configure test,
which tries to run the assembler to see if you have a new enough version
of GNU as that supports the necessary assembler reloc syntax.
Apparently this is going wrong with the native build.  Perhaps you have
a different binutils version, or perhaps there is a problem with your
PATH, or perhaps binutils and gcc weren't configured with the same
prefix, etc.

If you have the build trees, you can look at the gcc/config.h files and
note that one has HAVE_AS_EXPLICIT_RELOCS defined and the other doesn't.

--
Jim Wilson, GNU Tools Support, http://www.specifix.com







[-- Attachment #2: Type: text/html, Size: 2467 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread
* RE: Differing results from cross and native compilers
@ 2006-09-19 17:56 ` Eric DeVolder
  0 siblings, 0 replies; 15+ messages in thread
From: Eric DeVolder @ 2006-09-19 17:56 UTC (permalink / raw)
  To: Thiemo Seufer; +Cc: linux-mips

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Thiemo, could you share what the native 3.4 compiler reports as its configuration? (e.g. the "Configured with: " statement)?
 
Thanks,
Eric

________________________________

From: Thiemo Seufer [mailto:ths@networkno.de]
Sent: Tue 9/19/2006 12:16 PM
To: Eric DeVolder
Cc: linux-mips@linux-mips.org
Subject: Re: Differing results from cross and native compilers



Eric DeVolder wrote:
> Yes, it appears to me that the compiler (cc1) and assembler (as)
> invocations are the same. I've included the "-v" output of each
> below for reference. Furthermore, the -save-temps output .i files
> are effectively the same (differences due to cross vs. native paths,
> but that is it). Nonetheless, the output assembly source still
> contains differences!
> 
> I'm curious if anybody examined the output of a cross and native
> toolchain of the same (recent) version?

I get the same (properly optimised) result from both compilers:

  gcc (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)
  mips-linux-gnu-gcc (GCC) 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)


I haven't tried a 3.4 crosscompiler, but the native one also behaves
as expected:

  gcc-3.4 (GCC) 3.4.6 (Debian 3.4.6-4)


Thiemo



[-- Attachment #2: Type: text/html, Size: 2043 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Differing results from cross and native compilers
@ 2006-09-19 15:39 ` Eric DeVolder
  0 siblings, 0 replies; 15+ messages in thread
From: Eric DeVolder @ 2006-09-19 15:39 UTC (permalink / raw)
  To: linux-mips

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]

 
Hi, I have a MIPS native and cross compiler (gcc 3.4.4 and binutils 2.15)
both built using crosstool-0.42. I have an Alchemy system (MIPS32)
for which I am building code. When I compile a simple example, I get
different instructions from the cross and native compilers.
 
Specifically, the source file is:
 
 #include <stdio.h>
 int
 main (int argc, char **argv)
 {
     return -printf("Hello, world!\n");
 }
 
To compile natively, I use:
 
 % gcc -c hello.c -o obj1.o
 
To cross compile, I use:
 
 % mipsel-unknown-linux-gnu-gcc -c hello.c -o obj2.o
 
If I use the -O0 or -O1 flags with each, I get identical output
(for the .text), but when I compile in both environments with -O2;
the compilers produce different results.
 
The native compiler on the Alchemy board results in the following:
 
obj1.o:     file format elf32-tradlittlemips
Disassembly of section .text:
00000000 <main>:
   0:   3c1c0000        lui     gp,0x0
   4:   279c0000        addiu   gp,gp,0
   8:   0399e021        addu    gp,gp,t9
   c:   27bdffe0        addiu   sp,sp,-32
  10:   afbf0018        sw      ra,24(sp)
  14:   afbc0010        sw      gp,16(sp)
  18:   8f840000        lw      a0,0(gp)
  1c:   00000000        nop
  20:   24840000        addiu   a0,a0,0
  24:   8f990000        lw      t9,0(gp)
  28:   00000000        nop
  2c:   0320f809        jalr    t9
  30:   00000000        nop
  34:   8fbc0010        lw      gp,16(sp)
  38:   8fbf0018        lw      ra,24(sp)
  3c:   00021023        negu    v0,v0
  40:   03e00008        jr      ra
  44:   27bd0020        addiu   sp,sp,32
 
The cross compiler results in:
 
obj2.o:     file format elf32-tradlittlemips
Disassembly of section .text:
00000000 <main>:
   0:   3c1c0000        lui     gp,0x0
   4:   279c0000        addiu   gp,gp,0
   8:   0399e021        addu    gp,gp,t9
   c:   27bdffe0        addiu   sp,sp,-32
  10:   afbf0018        sw      ra,24(sp)
  14:   afbc0010        sw      gp,16(sp)
  18:   8f840000        lw      a0,0(gp)
  1c:   8f990000        lw      t9,0(gp)
  20:   00000000        nop
  24:   0320f809        jalr    t9
  28:   24840000        addiu   a0,a0,0
  2c:   8fbc0010        lw      gp,16(sp)
  30:   8fbf0018        lw      ra,24(sp)
  34:   00021023        negu    v0,v0
  38:   03e00008        jr      ra
  3c:   27bd0020        addiu   sp,sp,32
 
I would have thought that for this simple example I'd get identical
results. For reasons I have yet to figure out, the cross compiler is
finding better optimizations than the native, though both are the
same gcc version. I checked the specs files, and the two are identical
other than the "cross_compile" setting.
 
I'd like to solve this little mystery to get to the bigger prize, and
that is the ability to actually compile code (e.g. the entire system)
for MIPS32. As is demonstrated above, the compilers are generating
MIPS1 code (based on the NOPs between the load-to-use), but if I
could get the compiler to honor -mips32 (this discovery I originally
made while trying to get native -mips32 to work), I can get even
tighter code...
 
I've done quite a bit of googling to no avail. I've also done some
digging into gcc/binutils sources, and it appears that binutils has a
"from-abi" option for choosing its architecture, which is o32 which
probably means just MIPS1. I thought about trying to rebuild all the
tools for mipsisa32-unknown-linux-gnu, but am concerned I'd still
have the same problem of a particular compiler optimziation option
not being honored by the compiler.
 
Any tips/advice much appreciated, thanks!
Eric
 

[-- Attachment #2: Type: text/html, Size: 8212 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2006-09-21 14:54 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-19 16:57 Differing results from cross and native compilers Eric DeVolder
2006-09-19 16:57 ` Eric DeVolder
2006-09-19 17:16 ` Thiemo Seufer
2006-09-19 17:18 ` David Daney
2006-09-19 23:22 ` Jim Wilson
  -- strict thread matches above, loose matches on Subject: below --
2006-09-21 14:53 Eric DeVolder
2006-09-21 14:53 ` Eric DeVolder
2006-09-21 14:26 Eric DeVolder
2006-09-21 14:26 ` Eric DeVolder
2006-09-19 17:56 Eric DeVolder
2006-09-19 17:56 ` Eric DeVolder
2006-09-19 21:08 ` Thiemo Seufer
2006-09-19 15:39 Eric DeVolder
2006-09-19 15:39 ` Eric DeVolder
2006-09-19 16:05 ` Thiemo Seufer

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.