binutils 2.7 mipsorion64-elf question

binutils 2.7 mipsorion64-elf question

[Joel Sherrill <joel@merlin.gcs.redstone.army.mil>]

I am trying to verify that the newly submitted mips port of rtems 
compiles and was merged correctly and may have tripped across a problem:

The submitter was using the very old "cygnus-2.6.4-950101" whatever that is.

I am using binutils 2.7 and gcc 2.7.2 snapshot 960719 configured for 
mips64orion-rtems which is a clone of mips64orion-elf.

The warning from ld is:

liblnk.rel: uses different e_flags (0x0) fields than previous modules 
(0x20000001)
clock.rel: uses different e_flags (0x1) fields than previous modules 
(0x20000001)

I can't explain the reason why sometimes it is a 0x0 and sometimes it is 
a 0x1 but I think that all of the files with this problem were generated
using "ld -r".

Does this sound like a known/familiar problem or do you need some more 
information from me?

--joel

Re: binutils 2.7 mipsorion64-elf question

[Ian Lance Taylor]

   Date: Wed, 11 Sep 1996 13:11:43 -0500 (CDT)
   From: "Joel Sherrill <joel@merlin.gcs.redstone.army.mil>" <joel@merlin.gcs.redstone.army.mil>

   I am trying to verify that the newly submitted mips port of rtems 
   compiles and was merged correctly and may have tripped across a problem:

   The submitter was using the very old "cygnus-2.6.4-950101" whatever that is.

   I am using binutils 2.7 and gcc 2.7.2 snapshot 960719 configured for 
   mips64orion-rtems which is a clone of mips64orion-elf.

   The warning from ld is:

   liblnk.rel: uses different e_flags (0x0) fields than previous modules 
   (0x20000001)
   clock.rel: uses different e_flags (0x1) fields than previous modules 
   (0x20000001)

   I can't explain the reason why sometimes it is a 0x0 and sometimes it is 
   a 0x1 but I think that all of the files with this problem were generated
   using "ld -r".

   Does this sound like a known/familiar problem or do you need some more 
   information from me?

This is a known problem.  The 2.7 linker warns if you try to link
object files that look like they were compiled for different ISA
levels.  Unfortunately, the 2.7 ld -r always generates object files
that look like they were compiled for ISA level 0.  So, when you link
ld -r output with -mips3 output, you get a warning.

The bug in ld -r is fixed in the current snapshots, and will be fixed
in the 2.8 release.

The different between 0x0 and 0x1 is ignored (I hope).  A 0x1 just
means that .set noreorder was used in the source.

Ian