From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7431 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015) Date: Sat, 18 Apr 2015 18:54:36 -0400 Message-ID: <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 1429397696 32367 80.91.229.3 (18 Apr 2015 22:54:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Apr 2015 22:54:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7444-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 19 00:54: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 1YjbdW-0000xR-UP for gllmg-musl@m.gmane.org; Sun, 19 Apr 2015 00:54:55 +0200 Original-Received: (qmail 17771 invoked by uid 550); 18 Apr 2015 22:54:53 -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 17731 invoked from network); 18 Apr 2015 22:54:49 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7431 Archived-At: 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: "Error relocating %s: %s: symbol not found" "Error relocating %s: cannot allocate TLSDESC for %s", "Error relocating %s: unsupported relocation type %d", "Error loading shared library %s: %m (needed by %s)", "Error relocating %s: RELRO protection failed: %m", "cannot load %s: %m\n" "%s: Not a valid dynamic program\n" "Library %s is not already loaded" "Error loading shared library %s: %m" "Invalid library handle %p" "Symbol not found: %s" "Dynamic loading not supported" "Unsupported request %d" 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. 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). Rich