Re: binary to elf conversion

[Joel Sherrill <joel.sherrill@oarcorp.com>]

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
>