why gcc/objdump not recognize binary object file format

why gcc/objdump not recognize binary object file format

[Bridge Wu]

I got two ARM EABI toolchain and want to test their compatibility. One
is 3.4.4 (GCC version), the other is 4.1.0. The result is 4.1.0 can
link the binary code built by 3.4.4, but on the contrary, 3.4.4 cannot
recognize binary file format built by 4.1.0. Here is the result.

% arm-linux-gcc-3.4.4 -c t1.c
% arm-linux-gcc-4.1.0 -c t2.c
% arm-linux-gcc-3.4.4 t1.o t2.o
t2.o: file not recognized: File format not recognized
collect2: ld returned 1 exit status
% arm-linux-gcc-4.1.0 t1.o t2.o
[successful]

objdump in toolchain-3.4.4 also cannot recognize the file format built
by toolchain-4.1.0.

I took a look at the binutils source code. I found it's
bfd_check_format_matches that check the   file format. If target type
is not explicitly speicifed, bfd_target_vector list will be traversed
to check which target is matched. It seems this check was failed, so
the "File format not recognized" error appeared. I found below macro
do the checking.

     temp = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));

But I didn't find abfd->xvec->_bfd_check_format[] for ARM. I cannot
know what happened in the bfd_check_format function. Any hints?
Thanks.

-- 
best regards,
-Bridge

Re: why gcc/objdump not recognize binary object file format

[Nick Clifton]

Hi Bridge,

> I got two ARM EABI toolchain and want to test their compatibility. One
> is 3.4.4 (GCC version), the other is 4.1.0. The result is 4.1.0 can
> link the binary code built by 3.4.4, but on the contrary, 3.4.4 cannot
> recognize binary file format built by 4.1.0.

This does not actually tell us which version of the binutils is being 
used.  3.4.4 is a GCC version number, not a binutils version number.

> I took a look at the binutils source code. I found it's
> bfd_check_format_matches that check the   file format. If target type
> is not explicitly speicifed, bfd_target_vector list will be traversed
> to check which target is matched. It seems this check was failed, so
> the "File format not recognized" error appeared. I found below macro
> do the checking.
> 
>     temp = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));
> 
> But I didn't find abfd->xvec->_bfd_check_format[] for ARM. I cannot
> know what happened in the bfd_check_format function. Any hints?

Use a debugger to follow the execution path through this pointer.

For most ELF targets you will probably end up in 
bfd/elfcode.h:elf_object_p().  I suspect that you will find that the 
checks of the machine code values are the problem.  Otherwise look at 
the function bfd/elf32-arm.c:elf32_arm_object_p() and see if that is 
unable to recognise the 4.1.0 generated files.

Cheers
   Nick

Re: why gcc/objdump not recognize binary object file format

[Daniel Jacobowitz]

On Wed, Jun 07, 2006 at 10:59:30AM +0100, Nick Clifton wrote:
> Hi Bridge,
> 
> >I got two ARM EABI toolchain and want to test their compatibility. One
> >is 3.4.4 (GCC version), the other is 4.1.0. The result is 4.1.0 can
> >link the binary code built by 3.4.4, but on the contrary, 3.4.4 cannot
> >recognize binary file format built by 4.1.0.
> 
> This does not actually tell us which version of the binutils is being 
> used.  3.4.4 is a GCC version number, not a binutils version number.

Given the version numbers, I'm going to take a wild guess that these
are CodeSourcery toolchains.  If that's true, they were both 2.16.91
snapshots, from different dates.

> For most ELF targets you will probably end up in 
> bfd/elfcode.h:elf_object_p().  I suspect that you will find that the 
> checks of the machine code values are the problem.  Otherwise look at 
> the function bfd/elf32-arm.c:elf32_arm_object_p() and see if that is 
> unable to recognise the 4.1.0 generated files.

I'd guess this is caused by the new section types used by the ARM
tools, e.g. .ARM.attribute.  Binutils gives a somewhat unhelpful error
message for unsupported section types (although I vaguely remember HJ
improving this recently).

-- 
Daniel Jacobowitz
CodeSourcery

Re: why gcc/objdump not recognize binary object file format

[Bridge Wu]

Oh, sorry. The binutils version number in 3.4.4 is 2.15.96, and the
one in 4.1.0 is 2.16.92. Thanks your hints.

On 6/7/06, Nick Clifton <nickc@redhat.com> wrote:
> Hi Bridge,
>
> > I got two ARM EABI toolchain and want to test their compatibility. One
> > is 3.4.4 (GCC version), the other is 4.1.0. The result is 4.1.0 can
> > link the binary code built by 3.4.4, but on the contrary, 3.4.4 cannot
> > recognize binary file format built by 4.1.0.
>
> This does not actually tell us which version of the binutils is being
> used.  3.4.4 is a GCC version number, not a binutils version number.
>
> > I took a look at the binutils source code. I found it's
> > bfd_check_format_matches that check the   file format. If target type
> > is not explicitly speicifed, bfd_target_vector list will be traversed
> > to check which target is matched. It seems this check was failed, so
> > the "File format not recognized" error appeared. I found below macro
> > do the checking.
> >
> >     temp = BFD_SEND_FMT (abfd, _bfd_check_format, (abfd));
> >
> > But I didn't find abfd->xvec->_bfd_check_format[] for ARM. I cannot
> > know what happened in the bfd_check_format function. Any hints?
>
> Use a debugger to follow the execution path through this pointer.
>
> For most ELF targets you will probably end up in
> bfd/elfcode.h:elf_object_p().  I suspect that you will find that the
> checks of the machine code values are the problem.  Otherwise look at
> the function bfd/elf32-arm.c:elf32_arm_object_p() and see if that is
> unable to recognise the 4.1.0 generated files.
>
> Cheers
>    Nick
>
>
>


-- 
best regards,
-Bridge

Re: why gcc/objdump not recognize binary object file format

[Bridge Wu]

The toolchain-4.1.0 consists of GCC-4.1.0, GLIBC-2.4 and
BINUTILS-2.16.92. The toolchain-3.4.4 should be similar with
CodeSourcery toolchain, I'm not sure. Thanks your hints.

On 6/7/06, Daniel Jacobowitz <drow@false.org> wrote:
> On Wed, Jun 07, 2006 at 10:59:30AM +0100, Nick Clifton wrote:
> > Hi Bridge,
> >
> > >I got two ARM EABI toolchain and want to test their compatibility. One
> > >is 3.4.4 (GCC version), the other is 4.1.0. The result is 4.1.0 can
> > >link the binary code built by 3.4.4, but on the contrary, 3.4.4 cannot
> > >recognize binary file format built by 4.1.0.
> >
> > This does not actually tell us which version of the binutils is being
> > used.  3.4.4 is a GCC version number, not a binutils version number.
>
> Given the version numbers, I'm going to take a wild guess that these
> are CodeSourcery toolchains.  If that's true, they were both 2.16.91
> snapshots, from different dates.
>
> > For most ELF targets you will probably end up in
> > bfd/elfcode.h:elf_object_p().  I suspect that you will find that the
> > checks of the machine code values are the problem.  Otherwise look at
> > the function bfd/elf32-arm.c:elf32_arm_object_p() and see if that is
> > unable to recognise the 4.1.0 generated files.
>
> I'd guess this is caused by the new section types used by the ARM
> tools, e.g. .ARM.attribute.  Binutils gives a somewhat unhelpful error
> message for unsupported section types (although I vaguely remember HJ
> improving this recently).
>
> --
> Daniel Jacobowitz
> CodeSourcery
>


-- 
best regards,
-Bridge