binary to elf conversion

binary to elf conversion

[Joel Sherrill]

Hi,

I think something broke for converting binary
files to elf using objcopy.  I know I did this before
but can't seem to find a binutils that can do
this now.  I have tried both the RTEMS testing
version (a pre 2.18 snapshot) and our
stable repositories (something older)
and neither is able to link with the object file produced by objcopy'ing
a binary file  to a .o.

/opt/rtems-4.8/lib/gcc/powerpc-rtems4.8/4.2.1/../../../../powerpc-rtems4.8/bin/ld: 
unknown architecture of input file `o-optimize/tarfile.o' is 
incompatible with powerpc:common output

Produced by this command:

powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile 
o-optimize/tarfile.o

I tried mips and i386 and both fail with similar errors.

Is this working for anyone else on any target?

--joel

Can anyone do this

Re: binary to elf conversion

[Sergei Organov]

Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> Hi,
>
> I think something broke for converting binary
> files to elf using objcopy.  I know I did this before
> but can't seem to find a binutils that can do
> this now.  I have tried both the RTEMS testing
> version (a pre 2.18 snapshot) and our
> stable repositories (something older)
> and neither is able to link with the object file produced by objcopy'ing
> a binary file  to a .o.
>
> /opt/rtems-4.8/lib/gcc/powerpc-rtems4.8/4.2.1/../../../../powerpc-rtems4.8/bin/ld:
> unknown architecture of input file `o-optimize/tarfile.o' is
> incompatible with powerpc:common output
>
> Produced by this command:
>
> powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile
> o-optimize/tarfile.o
>
> I tried mips and i386 and both fail with similar errors.
>
> Is this working for anyone else on any target?

This never worked for me. Instead I use assembler to create empty .o
file, then add binary section to it using objcopy:

$ echo | as -o file.o
$ objcopy --add-section=section_name=file.bip file.o

-- Sergei.

Re: binary to elf conversion

[Andreas Schwab]

Joel Sherrill <joel.sherrill@oarcorp.com> writes:

> Produced by this command:
>
> powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile
> o-optimize/tarfile.o

You need to specify the binary architecture.

  -B --binary-architecture <arch>  Set arch of output file, when input is binary

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: binary to elf conversion

[Joel Sherrill]

Andreas Schwab wrote:
> Joel Sherrill <joel.sherrill@oarcorp.com> writes:
>
>   
>> Produced by this command:
>>
>> powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile
>> o-optimize/tarfile.o
>>     
>
> You need to specify the binary architecture.
>
>   -B --binary-architecture <arch>  Set arch of output file, when input is binary
>   
I don't know how it ever worked at all if I was missing that.
It arch going to always be the canonical name of the target
architecture?   I tried my powerpc and mips and it worked.

Why doesn't it default to the default architecture binutils was
built for?

I feel rather stupid since I know this used to work.  Thanks.
> Andreas.
>   

--joel

Re: binary to elf conversion

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

On Thursday 16 August 2007, Joel Sherrill wrote:
> Andreas Schwab wrote:
> > Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> >> Produced by this command:
> >>
> >> powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile
> >> o-optimize/tarfile.o
> >
> > You need to specify the binary architecture.
> >
> >   -B --binary-architecture <arch>  Set arch of output file, when input is
> > binary
>
> I don't know how it ever worked at all if I was missing that.
> It arch going to always be the canonical name of the target
> architecture?   I tried my powerpc and mips and it worked.
>
> 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 ;)

i imagine if you posted a patch, there wouldnt really be objections to the 
behavior change ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: binary to elf conversion

[H.J. Lu]

On Thu, Aug 16, 2007 at 09:55:29AM -0500, Joel Sherrill wrote:
> Hi,
> 
> I think something broke for converting binary
> files to elf using objcopy.  I know I did this before
> but can't seem to find a binutils that can do
> this now.  I have tried both the RTEMS testing
> version (a pre 2.18 snapshot) and our
> stable repositories (something older)
> and neither is able to link with the object file produced by objcopy'ing
> a binary file  to a .o.
> 
> /opt/rtems-4.8/lib/gcc/powerpc-rtems4.8/4.2.1/../../../../powerpc-rtems4.8/bin/ld: 
> unknown architecture of input file `o-optimize/tarfile.o' is incompatible 
> with powerpc:common output
> 
> Produced by this command:
> 
> powerpc-rtems4.8-objcopy -I binary -O elf32-powerpc tarfile 
> o-optimize/tarfile.o
> 
> I tried mips and i386 and both fail with similar errors.
> 
> Is this working for anyone else on any target?
> 

[hjl@gnu-6 tmp]$ file x
x: ASCII English text
[hjl@gnu-6 tmp]$ objcopy --version  -I binary -O elf32-i386 x y
GNU objcopy (Linux/GNU Binutils) 2.18.50.0.1.20070814
...
[hjl@gnu-6 tmp]$ file y
y: ELF 32-bit LSB relocatable, no machine, version 1 (SYSV), not stripped
[hjl@gnu-6 tmp]$

H.J.

Re: binary to elf conversion

[Maciej W. Rozycki]

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 imagine if you posted a patch, there wouldnt really be objections to the 
> behavior change ...

 ... which may actually be the reason nobody bothered to prepare such a 
patch so far.

  Maciej

Re: binary to elf conversion

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1151 bytes --]

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
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: binary to elf conversion

[Joel Sherrill]

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
>   

Re: binary to elf conversion

[Segher Boessenkool]

> 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?

You can use one of the many available "bin2c" style programs
for this; binutils contains one (used during SPU support builds),
the kernel contains one.

Or you can just use a linker script, if you have one target
only.

> I am looking for something cross-target and reliable.

I'd go for bin2c then.


Segher