From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12034 invoked by alias); 31 Oct 2012 13:58:03 -0000 Received: (qmail 11956 invoked by uid 22791); 31 Oct 2012 13:58:02 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 31 Oct 2012 13:57:54 +0000 Received: from eggs.gnu.org ([208.118.235.92]:51020) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1TTYnp-0007OG-8K for gcc-help@gnu.org; Wed, 31 Oct 2012 09:57:53 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTYnn-0005SW-IL for gcc-help@gnu.org; Wed, 31 Oct 2012 09:57:53 -0400 Received: from mail-ie0-f169.google.com ([209.85.223.169]:60143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTYnn-0005SP-DJ for gcc-help@gnu.org; Wed, 31 Oct 2012 09:57:51 -0400 Received: by mail-ie0-f169.google.com with SMTP id 10so2561084ied.0 for ; Wed, 31 Oct 2012 06:57:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.208.71 with SMTP id mc7mr1502077igc.47.1351691870390; Wed, 31 Oct 2012 06:57:50 -0700 (PDT) Received: by 10.64.102.68 with HTTP; Wed, 31 Oct 2012 06:57:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 31 Oct 2012 22:06:00 -0000 Message-ID: Subject: Re: How to identify Arch info when building From: naveen yadav To: Matthew Gretton-Dann Cc: gcc-help@gnu.org, binutils@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.223.169 X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg00181.txt.bz2 Thanks Matthew for your suggestion, the o/p is from linux-gnueabi-readelf -A . and what you suggest is what we want. At link time we should get error of mistmatch. >What you may be able to do (and I make no guarantees here) is add a > stage to your build which checks the attributes on the generated .so > after link to make sure that they match what you want. so is there any way at link time I can verify that a particular .so or .o is compile with different(ARM9), when build for A15. Thanks On Wed, Oct 31, 2012 at 7:11 PM, Matthew Gretton-Dann wrote: > This is a linker issue, and best asked on binutils@sourceware.org. > > On 31 October 2012 12:58, naveen yadav wrote: >> Hi All, >> >> I have two ARM arch (A9 and A15). and have cross compiler for both. >> >> Since code is integrated, some time .so got mixed(A9 with A15), and at >> run time it fails with undefined instruction. >> >> Is there any way to check strict at build time, we through an error. >> >> Scenario. >> >> (A15 code) + A9(.so)= executable when run on target (undefined instruction) >> >> Tag_CPU_name: "Cortex-A15" >> Tag_CPU_arch: v7 >> Tag_CPU_arch_profile: Application >> Tag_ARM_ISA_use: Yes >> >> >> Tag_CPU_name: "Cortex-A9" >> Tag_CPU_arch: v7 >> Tag_CPU_arch_profile: Application > > It is unclear where the different attributes above are coming from. > > The linker's checking for incompatibilities between objects is > restricted to examples like 'size of wchar_t == 2' is incompatible > with 'size of wchar_t == 4'. In this case it is obvious that these > two objects will never work together. > > When it encounters two objects where one uses features that are not > used in another (as for instance if you link objects for Cortex-A9 > which doesn't have integer-divide, and objects for Cortex-A15 which > does) the linker assumes the user wants to run the code on the most > 'feature'-ful. > > There is no way to tell the linker which CPU you intend to run the code on. > > What you may be able to do (and I make no guarantees here) is add a > stage to your build which checks the attributes on the generated .so > after link to make sure that they match what you want. > > Thanks, > > Matt > > -- > Matthew Gretton-Dann > Linaro Toolchain Working Group > matthew.gretton-dann@linaro.org