This is the mail archive of the
mailing list for the binutils project.
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 <firstname.lastname@example.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).