Cygwin hosted cross compilers

[gregory.menke at gsfc.nasa.gov]

Below is my original posting, I've learned a little more about it.  I
did a comparison of nm and objdump outputs from the Linux and Doze
generated objects.  Many of the objects were identical, but many
weren't.  The most obvious difference was a slightly different
strategy in the assembly generation.  

Generally, the Windows compiler seemed to do some 32 bit ops as 2 16
bit ops; set a register to 0 is done in one store word by the Linux
compiler, yet by 2 16 bit ops by the Windows version.  Quite strange,
maybe something to do with the optimizer.  The compiler flags are
exactly the same for both the Windows & Linux builds.

Does this ring any bells yet?

Gregm


 > > 
 > > We're sucessfully using the Linux hosted MIPS compilers for our R3000
 > > target, and are trying to bring up the Cygwin hosted ones so those
 > > cursed with Windows can compile the app.
 > > 
 > > The compilation is working OK, except a number of source files don't
 > > end up with the identical .o output file.  About half end up OK.  For
 > > those that aren't identical, comparing nm and objdump's output for the
 > > .o files generated for given .c file by the Cygwin and Linux hosted
 > > compilers shows the same symbols and the same assembly, but the
 > > addresses are shifted between a few bytes and quite a number.  Its
 > > almost as if sizeof() is returning something different- or code/data
 > > alignment is being performed differently.
 > > 
 > > This looks non-trivial because the same code compiled under Linux
 > > runs, but under Cygwin, fails with unaligned access exceptions in
 > > known good code.  RTEMS itself does start up, however.
 > > 
 > > I'm compiling under Cygwin using the ntvdm registry hack, and the
 > > makefile is identical for builds on either host.
 > > 
 > > I'm about ready do start more carefully comparing the output from a
 > > test .c file and try to narrow things down.  Has anyone seen similar
 > > behavior under Cygwin?
 > >