From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21879 invoked by alias); 16 Apr 2010 14:10:34 -0000 Received: (qmail 21857 invoked by uid 22791); 16 Apr 2010 14:10:33 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_SOFTFAIL,TW_BJ X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Apr 2010 14:10:29 +0000 Received: from mail.gnu.org ([199.232.76.166]:37649 helo=mx10.gnu.org) by fencepost.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2mFX-0002er-7m for gcc-help@gnu.org; Fri, 16 Apr 2010 10:10:27 -0400 Received: from eggs.gnu.org ([140.186.70.92]:39770) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1O2mFX-0005Vm-00 for gcc-help@gnu.org; Fri, 16 Apr 2010 10:10:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O2mFT-0006Jn-EK for gcc-help@gnu.org; Fri, 16 Apr 2010 10:10:25 -0400 Received: from smtp-out.google.com ([74.125.121.35]:22770) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O2mFS-0006Il-UU for gcc-help@gnu.org; Fri, 16 Apr 2010 10:10:23 -0400 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o3GEAJCB011228 for ; Fri, 16 Apr 2010 16:10:19 +0200 Received: from ewy23 (ewy23.prod.google.com [10.241.103.23]) by wpaz5.hot.corp.google.com with ESMTP id o3GEAH53001004 for ; Fri, 16 Apr 2010 07:10:18 -0700 Received: by ewy23 with SMTP id 23so1566004ewy.34 for ; Fri, 16 Apr 2010 07:10:17 -0700 (PDT) Received: by 10.103.50.13 with SMTP id c13mr1131668muk.63.1271427017333; Fri, 16 Apr 2010 07:10:17 -0700 (PDT) Received: from coign.google.com (adsl-71-133-8-30.dsl.pltn13.pacbell.net [71.133.8.30]) by mx.google.com with ESMTPS id n10sm13781516mue.12.2010.04.16.07.10.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 07:10:15 -0700 (PDT) To: trisha yad Cc: gcc-help@gnu.org, arm-gnu@codesourcery.com, Jie Zhang , David Daney Subject: Re: FW: gcc4.4.1 related doubt References: <4BAC58AC.3090100@codesourcery.com> <4BACFF1C.8010703@caviumnetworks.com> <4BB0E5D0.8050803@caviumnetworks.com> From: Ian Lance Taylor Date: Fri, 16 Apr 2010 20:40:00 -0000 In-Reply-To: (trisha yad's message of "Fri\, 16 Apr 2010 17\:47\:23 +0530") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-System-Of-Record: true X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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: 2010-04/txt/msg00185.txt.bz2 trisha yad writes: > a) Our problem : As discussed, some of the function symbol names > appear as T.XXX in the symbol-section of Linux kernel ELF file. > The build is OK and there is no script-fail issue here ( as Mr > Daney seems to think. ) > > Our company wants us to fix this problem. We dont want to "remove" > these symbols. Instead , we want that these symbols should > appear with the original function-names which they represent. > > For example, if there is a kernel-fault occurring near/after > T.XXX , we want the correct function-name to get displayed in > backtrace. > > We cannot change the toolchain version. We need Cortex support. > > Also , we dont think there is any connection to inlining here. > Looking at the objdump shows that T.XXX is a normal function which > gets called > with the usual bl call in ARM. So, you are asking how to disable the generation of the T.XXX functions? Those functions are clones created for better performance. If you give us a small test case showing the T.XXX function being created, we will tell you the command line option which will disable that specific optimization. By the way, at least with mainline -fno-ipa-cp-clone is a better approach than -fno-ipa-cp, since it does permit some optimizations. And, for what it's worth, the names used for clone functions in mainline gcc do include the name of the original function. Ian