|
Message-ID: <20150418225436.GA26589@brightrain.aerifal.cx> Date: Sat, 18 Apr 2015 18:54:36 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Reformatting dynamic linker error mesages? (or, Bikeshed April 2015) 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.