From: Florian Weimer <fweimer@redhat.com>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>, libc-alpha@sourceware.org
Cc: nd@arm.com
Subject: Re: [PATCH] Introduce --enable-math-noprivate
Date: Fri, 08 Jun 2018 12:11:00 -0000 [thread overview]
Message-ID: <e1c52d8b-23bd-8194-c663-da7a81f09404@redhat.com> (raw)
In-Reply-To: <fea525d3-f14b-bef6-007e-560566bab521@arm.com>
On 06/08/2018 11:03 AM, Szabolcs Nagy wrote:
>>> Ping. These patches
>>>
>>> <https://sourceware.org/ml/libc-alpha/2018-05/msg00501.html>
>>> <https://sourceware.org/ml/libc-alpha/2018-05/msg00541.html>
>>>
>>> allow building libm.so.6 without GLIBC_PRIVATE references on aarch64,
>>> and on x86-64 if --disable-multi-arch is also specified (I have a
>>> patch to add multi-arch support for the latter, but I need to come up
>>> with something that reduces the maintenance burden).
>>
>> Ping?
>>
>> What's the general feeling regarding this feature?
>
> independently updatable libm can be useful
> (or something that works from an LD_LIBRARY_PATH)
> when users of a very-stable-distro want to use the
> latest libm (assuming libm improves over time) or
> somebody wants to provide a libm with different
> precision guarantees.
>
> but i can see that ifunc may be ugly to implement.
> (or soft float, or fenv or strtod using nan)
The strtod/nan part should be covered by the second patch. I don't know
yet what the problems with soft float will be. To be honest, I'm not
particularly interested in soft-float. 8-/
IFUNC handling need per-architecture changes. On some targets, it
simply means removing IFUNC resolvers which always return the same
function. On other targets, it requires to duplicate the dispatching
logic found in libc inside libm.
There could be a problem if the dispatching logic depends on the
auxiliary vector passed by the kernel. libm will not have access to
that during relocation.
> if one updates libm.so will that also update math.h?
I don't think that will be easy to support.
> or we just want a libm with backward compatible abi?
For now, yes.
Thanks,
Florian
next prev parent reply other threads:[~2018-06-08 12:11 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-11 15:43 Florian Weimer
2018-05-11 16:36 ` Adhemerval Zanella
2018-05-11 17:23 ` Florian Weimer
2018-05-16 4:54 ` Florian Weimer
2018-06-07 13:38 ` Florian Weimer
2018-06-08 9:03 ` Szabolcs Nagy
2018-06-08 11:22 ` Adhemerval Zanella
2018-06-08 12:12 ` Florian Weimer
2018-06-08 12:56 ` Adhemerval Zanella
2018-06-08 12:11 ` Florian Weimer [this message]
2018-09-20 14:01 Florian Weimer
2018-09-20 16:27 Wilco Dijkstra
2018-09-20 16:35 ` Joseph Myers
2018-09-20 16:58 ` Florian Weimer
2018-09-20 17:11 ` Joseph Myers
2018-09-20 17:25 ` Florian Weimer
2018-09-20 17:35 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e1c52d8b-23bd-8194-c663-da7a81f09404@redhat.com \
--to=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
--cc=szabolcs.nagy@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).