This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Introduce --enable-math-noprivate
- From: Florian Weimer <fweimer at redhat dot com>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Cc: "libc-alpha\@sourceware.org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Joseph Myers <joseph at codesourcery dot com>
- Date: Thu, 20 Sep 2018 18:58:02 +0200
- Subject: Re: [PATCH] Introduce --enable-math-noprivate
- References: <DB5PR08MB103002AE08ED9CA20853906F83130@DB5PR08MB1030.eurprd08.prod.outlook.com>
* Wilco Dijkstra:
> My question is, would a new config option really be useful? Errno can
> be set outside the critical paths, so inlining it doesn't help at
> all. Therefore this should be done by default.
I can submit a patch to that effect, basically making that part
unconditional.
> Similarly the strtod_nan* dependency seems worthwhile to remove too.
I haven't thought about this. It's certainly a bit of a code
duplication.
Joseph, any thoughts on that?
> If these are the main dependencies between libc and libm, I can't see
> the value of adding a new config option.
The IFUNC resolvers on x86-64 use a GLIBC_PRIVATE symbol from ld.so.
That's going to be a bit more complicated to remove, and what we have to
do there is still a bit unclear to me. (I had a proof-of-concept patch
which actually reimplemented part of sysdeps/x86/cpu-features.c, but
didn't want to submit that so far.)
My expectation is that at least for x86, we'd still want
--enable-math-noprivate. (Maybe not in the distant future when we can
assume that H.J.'s new feature bit access interface is available
everywhere. 8-)
Thanks,
Florian