This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: binary to elf conversion
Mike Frysinger wrote:
On Friday 17 August 2007, Maciej W. Rozycki wrote:
On Thu, 16 Aug 2007, Mike Frysinger wrote:
Why doesn't it default to the default architecture binutils was
built for?
i think a similar question was posed for default -EB/-EL selection and
the answer was no one really cared enough to fix it ;)
One issue is for some architectures you cannot set some ELF file header
flags that may be needed for some uses of the resulting object file. For
example for MIPS/Linux you cannot set the PIC flag which makes the file
less that useful if you want it to become a part of userland binary. A
better solution these days is often to use `gas' (through the `gcc' driver
and hence accepting all the usual target-specific and less so object
generation options) and its .incbin directive instead...
i'd say this is to be expected ... the binary only contains so much
information so the resulting ELF is only as useful as what the binary
contains and what you give it
in other words, i dont think this sort of thing is enough to say the default
behavior of objcopy should remain the same
So objcopy from binary to linkable file isn't really the best
or most reliable way.
Sounds like I need to change the procedure on my side
to generate a .s file which defines the same symbolic
information around an incbin as objcopy did and then
assemble it with the same flags as the rest of the application.
Right?
Or would I be better off to write a program to dump the
binary file as a C file with an initialized array?
I am looking for something cross-target and reliable. For RTEMS
we convert a tar image of the initial RAM filesystem image into
an object and link it with the application.
--joel
--joel
-mike