This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH] Add generic HAVE_RM_CTX implementation
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Wilco <wdijkstr at arm dot com>
- Cc: 'Siddhesh Poyarekar' <siddhesh at redhat dot com>, <libc-alpha at sourceware dot org>, 'Marcus Shawcroft' <marcus dot shawcroft at gmail dot com>
- Date: Mon, 12 May 2014 14:57:55 +0000
- Subject: RE: [PATCH] Add generic HAVE_RM_CTX implementation
- Authentication-results: sourceware.org; auth=none
- References: <000101cf58af$83900a90$8ab01fb0$ at com> <20140430113915 dot GZ10922 at spoyarek dot pnq dot redhat dot com> <000601cf6479$a0d81590$e28840b0$ at com> <20140512060235 dot GD1224 at spoyarek dot pnq dot redhat dot com> <001e01cf6dda$1a976020$4fc62060$ at com>
On Mon, 12 May 2014, Wilco wrote:
> > Shouldn't this be __fegetenv and __fesetround? We shouldn't need to
> > go through the extra dereference since these functions are
> > internal-only. Likewise for all uses below.
>
> I agree we should avoid PLTs for internal calls. However I'm certain
> most targets wouldn't build if I used __fegetenv etc. libm_hidden_ver
> is used inconsistently, so this is yet another area that needs a cleanup.
As I said in <https://sourceware.org/ml/libc-alpha/2014-04/msg00471.html>,
PLT avoidance (via hidden_def etc.) is a separate matter from
namespace-cleanness (via __-prefixed names).
I think you can assume that for the symbols with libm_hidden_proto in
include/fenv.h, all architectures use libm_hidden_def (otherwise they'd
have had obvious build failures, at least if the symbol is in fact used
internally). *But*, if you want to use an __-prefixed name, you need to
make sure all architectures do in fact define that name and then use a
weak alias for the public name, as they may well not be consistent in that
regard. And it may still be useful to declare that __-prefixed name as
hidden (i.e. use attribute_hidden on the prototype) or use hidden_proto /
hidden_def with it; I'm not sure how important any compile-time
optimizations this enables are, but it does allow for such optimizations
at compile time rather than just at link time.
Namespace-cleanness is an issue here when the functions get used from C90
libm functions, since C90 doesn't include the <fenv.h> functions (I expect
it's also a pre-existing bug there and so any fix should include a bug
report in Bugzilla, etc.) - C90 functions shouldn't use the fe* names (or
a reserved name that brings in a non-reserved name as a *strong* alias).
It's not relevant for calls from non-C90 functions (e.g. those for float
and long double) except where in some other standard that lacks the
<fenv.h> functions (e.g. Unix98 has some of the C99 functions for double).
But in practice it would be fragile to rely on which math_private /
fenv_private facilities get called from which libm functions, so I think
systematically using the __-* names should be the eventual goal.
--
Joseph S. Myers
joseph@codesourcery.com