objcopy behavior question on non-octet targets

Ian Lance Taylor ian@zembu.com
Thu Mar 2 09:52:00 GMT 2000


   Date: Thu, 02 Mar 2000 09:20:50 -0600
   From: Joel Sherrill <joel.sherrill@OARcorp.com>

   I tried converting a binary file to a .o in order to link
   it into an executable. I use this trick to include things
   like tar images in executables.  It works as expected on
   "normal CPUs " that are byte-addressable.

   On the TI C3x/C4x (target=c4x-rtems == c4x-coff), the size
   of the resulting object file was 4x that of the binary image.
   I assume this is because each byte in the binary file becomes
   one 32 bit word in the coff file.

   I was hoping it would end up being packed denser than this.
   I don't know what the behavior should be and suspect that there
   is no right answer.  The file created is technically an array
   of unsigned chars so I understand how the output is correct
   based on this interpretation.

   I would like to hear others opinions on what is useful/correct/expected.

At least in principle, you should be able to link in a binary file
directly, by using the -b binary option when you invoke the linker.

When converting a binary to a .o, I suppose the objective should be
that when the .o is linked, the result is roughly equivalent to the
binary, with only changes due to addressing, alignment and the like.

So I think I would call the behaviour you are describing a bug.

Ian


More information about the Binutils mailing list