From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13821 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Stdio resource usage Date: Wed, 20 Feb 2019 11:49:01 +0100 Message-ID: <20190220104901.GU21289@port70.net> References: <20190220024313.GA23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="260668"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) To: musl@lists.openwall.com Original-X-From: musl-return-13837-gllmg-musl=m.gmane.org@lists.openwall.com Wed Feb 20 11:49:17 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gwPRE-0015iW-5p for gllmg-musl@m.gmane.org; Wed, 20 Feb 2019 11:49:16 +0100 Original-Received: (qmail 22526 invoked by uid 550); 20 Feb 2019 10:49:13 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22506 invoked from network); 20 Feb 2019 10:49:13 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20190220024313.GA23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13821 Archived-At: * Rich Felker [2019-02-19 21:43:13 -0500]: > On Tue, Feb 19, 2019 at 03:34:52PM -0800, Nick Bray wrote: > > I don't expect any of these modifications to make it > > upstream. Talking out loud as a FYI / user feedback. Also curious to see > > if there's any wisdom out there. > > > > Stack usage of stdio was an issue. On arm64, printf takes 8k of stack > > which is a rough when you only have 4-12k of stack. This is because fmt_fp > > allocates stack space proportional O(log(MAX_LONG_DOUBLE)). It also gets > > inlined into printf so you always take the hit. (noinline fmt_fp is a > > This is a known compiler flaw, hoisting large stack allocations, and > one I've complained a lot about but with little luck. It might be > possible to work around it by making the array a VLA, whose size is 1 > or the proper size depending on some condition the compiler can't > easily see, but that's rather awful. It might be worth doing though, > given the lack of progress fixing the bug. i think it's just an llvm issue, or does this happen with gcc too now? > > Faustian bargain that makes stack usage worse in the worst case... hmmm.) > > On arm64, long double is defined as 128 bits, which not only increases > > stack size because of the larger mantisa, but also pulls in software note: the mantissa is not the real issue, the exponent range is. (e.g. to printf 0x1p-16494L you need to compute 5^16494/10^16494 which is floor(log10(5)*16494) + 1 = 11529 digits) > > emulation for fp128. In terms of spec compliance, Musl is doing the right > > thing. But as a practical matter, none of the programs I care about will > > ever use long double. So my rough first pass was to reduce the max float > > size from long double to double. In a later pass, I'll also add a knob to > > remove floating point formatting entirely. > > It's kinda unfortunate that aarch64 defined long double as IEEE quad > without hardware implementation of it, but it's probably the right > future-facing choice. I was under the impression that aarch64 was > intended mostly for "large" systems, and that you'd use 32-bit arm > (with much smaller code due to thumb) for tiny space-constrained > systems, though. aarch64 has 128 bit fp regs, so in principle future arch extension may add 128bit instructions without breaking abi. (which may happen if aarch64 gets adoption in supercomputers, e.g. powerpc64 did that) > > %m calls strerror which pulls in a string table, so removing support for %m > > lets static linking and DCE work its magic. > > Yes. Note that %m is needed for a confirming syslog(), which was the > motivation for supporting it in printf. > > > I also eliminated %n for > > security hardening reasons. > > This actually introduces security bugs by breaking the contract. At > some point I believe there may even have been some parts of musl you > would have broken in dangerous ways, though I'm not sure if that's the > case now. If you have a situation where the format string is > non-constant, that, not %n, is the problem. i think %n is not a huge loss, but it does sound like repeating the bionic mistakes. (providing posix symbols with slightly not posix conform semantics because of speculative resons which turned out to be a lot more expensive to fix up than just following the standard)