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

[Isaac Dunham <ibid.ag@gmail.com>]

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