Re: [PATCH roland/arm-mcount] ARM: Disable compat mcount code when unneeded.

["Joseph S. Myers" <joseph@codesourcery.com>]

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