Reformatting dynamic linker error mesages? (or, Bikeshed April 2015)

[Rich Felker <dalias@libc.org>]

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