From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32060 invoked by alias); 7 Jun 2006 14:24:51 -0000 Received: (qmail 32050 invoked by uid 22791); 7 Jun 2006 14:24:51 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.170) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Jun 2006 14:24:45 +0000 Received: by ug-out-1314.google.com with SMTP id s2so315821uge for ; Wed, 07 Jun 2006 07:24:29 -0700 (PDT) Received: by 10.78.20.13 with SMTP id 13mr160133hut; Wed, 07 Jun 2006 07:24:29 -0700 (PDT) Received: by 10.78.70.5 with HTTP; Wed, 7 Jun 2006 07:24:22 -0700 (PDT) Message-ID: <246188420606070724u11369b9eo926ac89975dad162@mail.gmail.com> Date: Wed, 07 Jun 2006 14:27:00 -0000 From: "Bridge Wu" To: "Nick Clifton" Subject: Re: why gcc/objdump not recognize binary object file format Cc: binutils@sourceware.org In-Reply-To: <4486A382.30804@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <246188420606070036r49498b50i2476567ca76250c@mail.gmail.com> <4486A382.30804@redhat.com> Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00078.txt.bz2 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 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