From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7464 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015) Date: Wed, 22 Apr 2015 00:37:41 +0000 Message-ID: <20150422003740.GB1773@Sparta> References: <20150418225436.GA26589@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1429663076 8146 80.91.229.3 (22 Apr 2015 00:37:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 22 Apr 2015 00:37:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7477-gllmg-musl=m.gmane.org@lists.openwall.com Wed Apr 22 02:37:55 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Ykifo-0003MB-Nt for gllmg-musl@m.gmane.org; Wed, 22 Apr 2015 02:37:52 +0200 Original-Received: (qmail 24379 invoked by uid 550); 22 Apr 2015 00:37:51 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 24361 invoked from network); 22 Apr 2015 00:37:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gj9J27AHQwB6c5DNz493iS4lr2RV0v8Q1mef428tznY=; b=iTptQDC0PSr+HCda+Q8Vg4afAG9IYLnOklTzOdKZvPW+W3C2mocNNSHoJ+uA2I3KYR WoNSeIIvmI4LxxhMNswIuU2QkuF0NZ6C6kC6FaRs5IzMaUEUUcQirIXrzTMuB3YhpgXp doo/OfkSl0w5EtPPHBzYgvEtIqptXUvGYe694q1Nb+LMH+Wa4w+lID6LcqVYf8/30u0b F8fteRHezcwARbeTCJIvJuk2Md5fXGDOy4g+LtRxLbiPX1DT+Csio7nH3eeBHAbhnt3H 01NZQJ+r0Rnyqy5nMea6E0XoEXmuiuqq4rjuU0eQB8JKs3AbWybRo7fBbvUTot2BpUcl QKLw== X-Received: by 10.70.90.129 with SMTP id bw1mr42173200pdb.85.1429663058654; Tue, 21 Apr 2015 17:37:38 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20150418225436.GA26589@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:7464 Archived-At: On Sat, Apr 18, 2015 at 06:54:36PM -0400, Rich Felker wrote: > One item on the roadmap that I want to work on is making the dynamic > linker error strings translatable. Since (unwritten, maybe) policy is > that we don't translate format strings in libc (it makes untrusted > locale files dangerous), this is going to require at least > restructuring of the code that generates the messages, and also calls > for restructuring of the actual text. I'm looking for ideas on how to > do this and make it the most legible and informative. > > The errors we have to worry with are: [reordered to make redundancy more obvious] > "Symbol not found: %s" > "Error relocating %s: %s: symbol not found" > "Error relocating %s: cannot allocate TLSDESC for %s", > "Error relocating %s: unsupported relocation type %d", > "Error relocating %s: RELRO protection failed: %m", > "Error loading shared library %s: %m (needed by %s)", > "Error loading shared library %s: %m" > "cannot load %s: %m\n" > "%s: Not a valid dynamic program\n" > "Library %s is not already loaded" > "Invalid library handle %p" > "Dynamic loading not supported" > "Unsupported request %d" It looks like there's a bit of redundancy here, where 2-5 share "Error relocating %s", 6 and 7 share "Error loading shared library", and 1 and 2 share (save capitalization) "symbol not found". It would be nice to see that redundancy turned into shared submessages. I also notice that there's a mix of two equivalent formats: error("...%m...") and dprintf(fd, "...%s...", strerror(errno)) which I find odd. Do we want the calls to strerror(errno) converted to something localized? If so, %m would seem to be harmful. On the other hand...is localization set up this early? > I think we should aim to separate it into a :-delimited form where > there's no grammatical relationship between fields, since making > grammar fit multiple natural languages is basically impossible. Agreed. > Note that some of the above error messages are bad to begin with. We > don't necessarily need to preserve the content as-is; I'd much rather > make the error messages better at the same time. > > For errors loading/mapping a library, I think we need to report the > cause, which could be: > - System-level errors opening/reading/etc. > - File-format errors > - Memory-allocation failure > > It may also be useful, if the failing library is being loaded as a > dependency for another library, to report the library that needed it. > For errors during relocation, we need to report the library that could > not be relocated, and the reason, which could be: > - Missing symbol (need to show which symbol) > - Unknown/invalid relocation type > - Memory-allocation failure > - System-level failures (mprotect, etc.) > > Everything else looks pretty straightforward. > > It's also unclear to me whether we should aim to change the signature > of the error() function to take fixed fields, which error() is then > responsible for translating, or whether the caller should translate > fixed strings going in (in which case the caller has freedom to use > lots of different formats). Consider these strings: > "Error loading shared library %s: %m (needed by %s)", > "Error relocating %s: cannot allocate TLSDESC for %s", > "Error relocating %s: %s: symbol not found" Looking at the strings in question, it seems clear to me that we will need to intermix translated and untranslateable strings to make the meaning clear. While the error message can be adjusted, it gets hard to comprehend the error when data is not adjacent to its explanation. Theoretically, you could stipulate that every other field is translated and empty strings are skipped, but that sounds rather brittle. Thanks, Isaac Dunham