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