From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30558 invoked by alias); 29 Aug 2013 23:45:21 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 30544 invoked by uid 89); 29 Aug 2013 23:45:20 -0000 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 Aug 2013 23:45:20 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE,SPF_HELO_FAIL autolearn=no version=3.3.2 X-HELO: relay1.mentorg.com Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1VFBtp-0000gz-Pn from joseph_myers@mentor.com ; Thu, 29 Aug 2013 16:45:13 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Aug 2013 16:45:14 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Fri, 30 Aug 2013 00:45:12 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1VFBtm-0001wF-Qr; Thu, 29 Aug 2013 23:45:10 +0000 Date: Thu, 29 Aug 2013 23:45:00 -0000 From: "Joseph S. Myers" To: Roland McGrath CC: Subject: Re: [PATCH roland/arm-mcount] ARM: Disable compat mcount code when unneeded. In-Reply-To: <20130829232658.5B2002C072@topped-with-meat.com> Message-ID: References: <20130827173014.D264D2C097@topped-with-meat.com> <20130829232658.5B2002C072@topped-with-meat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-08/txt/msg00071.txt.bz2 On Thu, 29 Aug 2013, Roland McGrath wrote: > > Isn't this about objects built with old compilers (before GCC 4.4, when > > __gnu_mcount_nc was introduced; arm*-*-linux-gnueabi support was added in > > 4.1), which is generally supported, rather than objects built with old > > library headers, which isn't? > > I see. I'd still like to find a way to exclude this code from > configurations that will never use it, i.e. a target for which there was > never a compiler that produced _mcount calls. But perhaps there is no > "generic" way to achieve that. I suppose I can just move it to a separate > file and let my configuration drop that file from sysdep-routines. > > I think the ideal would be if we dropped it from the shared library (except > for a compat_symbol where needed, of course) and had it only in > libc_nonshared.a. But I can't see a way to e.g. write _mcount in terms of > calling __gnu_mcount_nc (without breaking the profile so that it only > tracks _mcount itself as the callee), and I don't want to expose something > like __mcount_internal in the ABI just so that _mcount can call it. > > Can you think of anything better? I don't have anything better in general. It does occur to me that for the hard-float ABI (__ARM_PCS_VFP) it would be OK in principle to make the old entry point into a compat symbol in the shared library and remove it from the static library, so not available for new links, given that the hard-float ABI wasn't supported before GCC 4.5 (and GCC has never supported marking objects that don't use floating point as "don't care" for the ABI, so soft-float objects built with older GCC couldn't be used with a hard-float libc). But that's probably not worthwhile (and conditioning something that's nothing to do with floating point on the floating-point ABI would at least be rather confusing). -- Joseph S. Myers joseph@codesourcery.com