RE: Cross-Compiling Help

[Ruppert <dieter_ruppert at siemens dot com>]

> 
> Well, I was able to extract the .text section thanks to the suggestion from
> Ruppert (thanks).  The comparison wasn't pretty.  Actually, I am trying just
> a simple "hello_world" type program and the diff of the objdump didn't look
> good at all.  Ruppert, can you or anyone else tell me how to get the map
> file using gcc?  I'm not familiar with the GCC toolset and I would like to
> see the difference between the map files for the two objects.

Add 

      -Wl,-Map,foo.map
      
(no blanks in between) to your link command line (see the docs for GNU ld, 
also part of binutils).


> 
> Also, we compared the assembly code generated by gcc (gcc -S) and the code
> generated by the cross-compiler gcc and the native gcc were identical!  We
> then executed gcc -c for each and compared the unlinked binaries (assembled
> code) and the two binaries were again an exact match.  But when we go to
> link the objects (gcc -o foo.o foo.c), that's when everything changes.

This indicates that the assembler works as expected.

> 
> The stripped binaries match in size, but using cmp to compare the two, they
> do not match.  I compared the objdumps and they do match up to a point and
> then the rest of the file does not match (only about 1/10th match and then
> the assembly instructions are very different after that).
>

The linker combines your objects with "startup code" and libraries (use 
-v on the link command line to see the complete invocation of ld). Maybe
the difference is from one of these components. You should be able to
deduce this from the link map: add the offset of the first difference
(from cmp) to the .text start address (in the mapfile) and locate the
corresponding module in the mapfile. If this is within startup code (modules
with names like crt0.o, crtbegin.o etc.) or within library code then your
linkers pick up different startup code modules or libraries.

Regards
D.Ruppert