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


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


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