This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]